[FFmpeg-devel] [PATCH] Metadata

[Baptiste Coudurier]

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, and especially wrong if 'key'
contains '-' in its name.

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.

[...]

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no