[FFmpeg-devel] [PATCH] metadata conversion API

[Baptiste Coudurier]

On 2/28/2009 1:43 PM, Michael Niedermayer wrote:
> On Sat, Feb 28, 2009 at 01:24:41PM -0800, Baptiste Coudurier wrote:
>> On 2/28/2009 5:57 AM, Michael Niedermayer wrote:
> [...]
>>>>> * more compatibility for apps, apps already can through 
>>>>> AVOptions set and get by name and enumerate fields.
>>>> AVOptions uses OPT_<type> isn't it ? Why don't you want to
>>>> apply this to AVMetadata ?
>>> i explained it already above:
>>>>> [...] This has the advantage that it can be muxed in
>>>>> containers that do not support storing such information.
>>> [...]
>>>>> Or how would you store these types? If they are lost on
>>>>> remuxing or their types are randomized then they arent
>>>>> particularely usefull IMHO
>> Well, they are useful to gather information, print metadata and 
>> debugging, maybe less useful for remuxing inter-container, however,
>> mov to mov could end in a pretty accurate way.
>> 
> 
>> Exporting all information using AVFormatContext fields will lead to
>> an huge struct.
> 
> exporting all fields as name value pairs will consume more memory 
> what i mean is, an int needs 4 bytes a av_malloc() will need at least
> 16 byte due to alignment alone but i would not be surprised if it
> needs twice that to keep track of things so malloc& free work now
> each metadata tag contains 2 strings, if we assume both fit in the 16
> byte and no additional byte is needed to keep track of things then 
> theres 16 bytes for ther struct (2 8byte pointers on 64bit archs) 
> +16*2 byte for the 2 strings thats 48 byte in the very best case, in
> reality it will need more
> 
> that makes it 4 byte for a field in a struct and that could be
> reduced to 1 byte for many things and 48 byte for a name-value tag
> 
> that means you need 12 times more unused fields than fields in the 
> struct just to make the name-value tags need the same amount of
> memory. and if its about 1 byte fields the factor is 48 instead of
> 12.
> 
> maybe this explains why i disslike them so much * slow to access *
> memory hungry
> 
> also there union{} and one can place structs in structs to make the
> source clearer than a monolithic struct.

I believe the code to print everything would be a pain in the ass.
You will have to iterate over all fields. I think it is worth to
consider easy access.

It's like to code handling lang mechanism in new metadata API, it is
_ugly_, implementation prove it.

Also I believe this would simplify adding support for libx264
commandline switches in libx264 wrapper, since you do not needed an API
extension in AVCodecContext, for it due to x264_parm_parse which takes
exactly 2 char *. This is what I call generic API.

On the other end, you could explicitly instruct the demuxer to not
populate metadata, this would save more bytes than your solution, since
the context will be smaller.



-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org