[FFmpeg-devel] [PATCH] Metadata
Michael Niedermayer
michaelni
Mon Jan 5 22:59:24 CET 2009
On Mon, Jan 05, 2009 at 11:40:12AM -0800, Baptiste Coudurier wrote:
> Hi Michael,
>
> Michael Niedermayer wrote:
> > On Sat, Jan 03, 2009 at 03:26:05PM -0800, Baptiste Coudurier wrote:
> >> Hi Michael,
> >>
> >> Michael Niedermayer wrote:
> >>> [...]
> >> >
> >>> + * 3. A tag whichs value is translated has the ISO 639 3-letter language code
> >>> + * with a '-' between appended. So for example Author-ger=Michael, Author-eng=Mike
> >>> + * the original/default language is in the unqualified "Author"
> >>> + * A demuxer should set a default if it sets any translated tag.
> >> >
> >>> [...]
> >> >
> >>> +typedef struct {
> >>> + char *key;
> >>> + char *value;
> >>> +}AVMetaDataTag;
> >> Maybe it would be simpler and more extensible to have a "const char
> >> **attributes" field where to store language, or anything else related to
> >> the AVMetaDataTag entry. This would avoid parsing the '-'.
> >>
> >> What do people think ?
> >
> > I am against it, let me explain why
> >
> > First, currently metadata support in svn is "too little" that is nothing
> > is really supported, no preserving of arbitrary tags, no way for users to
> > add anything but 5 standard tags ...
>
> I definitely agree.
>
> > Aurels variant, that had a language field and did use a tree based metadata
> > system allowing metadata about metadata is IMHO "too much" Its not something
> > anyone should need, nor is it really needed for language & metadata about
> > metadata, and still it wouldnt be able to handle all metadata about other
> > metadata like "the email address of the child of the author and producer"
> >
> > my sugestion of a simple key-value based system
> > can be stored in any container that supporte key-value string based
> > metadata, and still can represent language and metadata about other metadata.
> > Also it can very easily be implemented efficiently, currently all operations
> > are O(n) thus it would become slow if there are many tags. But if we would
> > use tree.c/h it would all just be O(log n) and its very easy to use tree.c/h
> > with it ...
> >
> > Now if we do add attributes
> > * The api to search for tags becomes more complex
> > * It is more difficult to use tree.c/h (it needs like qsort a sanely
> > behaving comparission function, which is trivial for char*, less
> > so with an additional attriute list, and even a lot less if we want
> > to actually search for specific attributes)
> >
> > * No container i know supports arbitrary attributes, thus muxers would
> > either have to convert the attribute list into a string or extract the
> > 2 or 3 they suport.
>
> Well, these are good point.
> To be clear, I'm not suggesting a tree metadata scheme, but a way to
> easily specifiy this key/value metadata details.
>
> Like language, type (comes from .mov so excpect '\r' as line separator,
> encoding is UTF8, etc...)
>
> Parsing for '-' is not convenient,
either theres a single string, in which case some muxers have to parse for -
or
there are many fields, in which case some other muxers have to combine them
in a single string.
The convertion doesnt dissapear and because of this IMHO i would prefer the
simpler internal repressentation.
> and especially wrong if 'key'
> contains '-' in its name.
'-' was just an idea, we could easily switch to another char based on
* it should be printable (so a user can enter & see it easily)
* it should be a ASCII char (0..127)
* it should be very unlikely to occur in a valid&sane key
* it should interfere little with /bin/sh command line handling
>
> Itunes and .mp4 contains language for each metadata item.
>
> > * The user interface from the command line would be more complex, or it
> > would be maybe just a string but then why not keep the string internally
>
> Well -metadata "author"="baptiste":"lang"="eng" with escaping is not
> that complex IMHO.
thats true
but similarly, its not that complex either to do it in the demuxer
and have just 2 strings.
key='author,lang=eng'
value='baptiste'
internally
I mean the parsing stays the same its just done somewhere else.
Like calling a av_metadata_split_key(key_string, &key, &lang)
Also, i belive escaping, no matter if from the command line or internally
is overkill.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090105/13c5d391/attachment.pgp>
More information about the ffmpeg-devel
mailing list