[FFmpeg-devel] [PATCH] Metadata

[Baptiste Coudurier]

Aurelien Jacobs wrote:
>>>>> [...]
>>>>>
>>>>> 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.
>> Which muxers ?
>> How does .mkv stores lang metadata info if it does so ?
> 
> mkv is similar to mov. It stores tags lang in it's own field (ISO 639-2).
> 
>> All I see is that for .mov you would have to concatenate key name and
>> lang, and muxer would have to split lang from metadata.
> 
> In fact you would just call av_metadata_set_with_lang() and
> av_metadata_get_with_lang() instead of the basic API.
> (possibly with better functions name)
> Duplicating this concatenation/splitting in every (de)muxers
> which need it would be bad.
>
>> I don't know of any container that use "key"-"lang" at metadata scheme
>> (nut maybe ?).
> 
> This is indeed the currently proposed format for nut.

Duplicating is bad of course, though designing based on what only nut
supports appears limited, especially when .mov and .mkv does differently.

it seems either
.nut would have concatenate key-lang (very simple with put_buffer)
.mov and .mkv would need to check the presence of "lang" attribute.
.avi would ignore the lang (is this correct ?)
or
.nut would write the key "as is"
.avi, .mov and .mkv will need to extract lang and write it separately or
not all all for .avi

Furthermore, if the plan is to provide an API to set with lang and get
with lang, I don't see any practical interest of using '-' internal
representation, this means adding string manipulation code inside lavf,
and limitations.

>>> The convertion doesnt dissapear and because of this IMHO i would prefer the
>>> simpler internal repressentation.
>> How would you specify to the user that data stored in value is raw data
>>  (like jpeg cover), encoded in UTF8/16, special like '\r' line ended ?
>>
>> I believe we need a way to specify this to facilitate usage, and this
>> could fall into attributes.
> 
> Ideally we should support only one common format (UTF8, etc...) so that
> data can be re-muxed between any containers.

Well, we could export what is actually stored in the file, treatment
could be left to the user (before someone requests to access 'raw' data
stored).

For the muxing case, I guess requiring a common format is simpler to
deal with.

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