[FFmpeg-devel] [PATCH] metadata conversion API

Michael Niedermayer michaelni
Sat Feb 28 22:43:35 CET 2009

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.


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- 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/20090228/e6bed7b3/attachment.pgp>

More information about the ffmpeg-devel mailing list