[FFmpeg-devel] [PATCH] Implement libavcodec/opt.[ch] generic options handling

Michael Niedermayer michaelni
Thu Oct 15 16:36:54 CEST 2009

On Tue, Oct 13, 2009 at 11:38:37PM +0200, Stefano Sabatini wrote:
> On date Tuesday 2009-10-13 12:04:01 +0200, Michael Niedermayer encoded:
> > On Tue, Oct 13, 2009 at 01:58:24AM +0200, Stefano Sabatini wrote:
> > [...]
> > > } AVOption2;
> > > 
> > > Would be that an acceptable move towards an acceptable solution?
> > 
> > honestly this all is very messy
> > maybe we can just repace default_val by an union of double and char* and add
> > a flag to indicate that its a char*, this with some luck should maintain
> > compaibility.
> > 
> > and i do not see why a overrideable set_string() would make sense
> > add your code to the existing set_string()
> > 
> > 
> > > 
> > > Having just a set_string handler and a string with the default value
> > > (as opposed to my idea of using also a set_default_value() handler)
> > > looks like a good idea.
> > > 
> > 
> > > Still I miss how would be possible to pass some parameters (e.g. min,
> > > max, offset1, offset2) to a specific option, you somehow disliked my
> > > idea of using an opaque field for that.
> > 
> > i dont understand what you want to do with set_string() here?
> [...]
> Let's put it in another way: consider this example, I want to set an
> option which takes in input a string representing a color, and I want
> to put the corresponding color somewhere inside a context. 
> Without a set_string callback, the only possible way to do it would be
> to extend opt.c, which is exactly what I want to avoid. Why? Because
> the function I'll use for setting that option may not be defined in
> libavcodec. Also I don't want to make opt.c grow and grow every time I
> need a specialized function for setting an option.

Ive already in the past rejected this hybrid system. You try again with the
very same system ...
Its poor design, first the whole need of having user supplied parsing
functions is somewhat unclear to me. I mean the whole is for patches i
rejected and IIRC that was not the only nor primary reason for their
rejection but i might misremember ...

AVOptions have a variable called type, it specifies which type the
underlaying field is (float/string/color/flags/...)
this variable selects which parser / set_string code is used
Currently all these parsers are inside opt.c, they could be moved
into opt_parser.c or we could even allow an user app or a libav*
to register its own parsers for some types. But completely
bypassing the existing framework, and to make that not blow up
rewrite it all using a new AVOption2 filled with callbacks, is
simply just a mess.

> Show me how to do it without to extend opt.c and I'll be happy, just
> telling that such a feature isn't worth the trouble is not an option
> (pun intended).

see above but i still have my doubts about it being a good idea
The only thing that becomes possible with it is putting the code in a
different libraray or into the user app, i dont see the point of that

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- 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/20091015/1248e5b8/attachment.pgp>

More information about the ffmpeg-devel mailing list