[FFmpeg-devel] [PATCH] metadata conversion API

[Michael Niedermayer]

On Sat, Feb 28, 2009 at 02:24:45PM -0800, Baptiste Coudurier wrote:
> 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.

huh?
if i compare the current metadata API with what was originally proposed
then the original with seperate lang field was much uglier and much bigger
loc wise


> 
> 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.

the question is if we _WANT_ to let a encoder bypass the normal way to
pass parameters. 
If the awnser to this is yes, its a matter of a single char* generic_param
in AVCodecContext with which encoders can do what they want.
If the awnser OTOH is no then the name-value tags wont help you, you still
would need a common documented set and do translation on some ...

also the first step is to ask the question on ffmpeg-dev if we _WANT_ to
let a encoder bypass the normal way to pass parameters.

the second step is to actually have someone work on the libx264 wraper,
i mean you claim that the name-value lists would help code that is crap
because noone works on it not because anyone would have rejected some
patch or because there would be a difficult problem.


> 
> 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.

that assumes that the fields are all useless for the users task, this is
extreemly unlikely
if its about true metadata like Author, that exists in a name-value list
alraedy and could, would someone actually care be disabled

the other fields that we talk about (everything that exists as a field in
AVCodecContext currently) arent that useless that you would achive the
12-48 times more unused than used factor IMHO.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- 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/20090301/0f533d06/attachment.pgp>