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

Stefano Sabatini stefano.sabatini-lala
Fri Oct 16 01:06:31 CEST 2009

On date Thursday 2009-10-15 16:36:54 +0200, Michael Niedermayer encoded:
> On Tue, Oct 13, 2009 at 11:38:37PM +0200, Stefano Sabatini wrote:
> Ive already in the past rejected this hybrid system. You try again with the
> very same system ...

+hybryd-rewrite -> rejected
-hybrid+rewrite -> rejected

You rejected both approaches, now I don't know if there is another
available -hybrid-rewrite approach, which allows all the features I
would like.

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

One of the things I object to the current system is that the types are
statically defined, so I wonder how would be possible to register new
types at run-time.

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

Again consider my example, the parsing code for a color is currently
implemented in lavfi, in order to implement an OPT_TYPE_COLOR you
would have to:

1) re-implement in lavc/lavu/wherever-the-opt-system-is the parsing

2) move the color parsing code to wherever-the-opt-system-is.

which are both rather poor choices.

Also an application (e.g. ffmpeg) may want to use the option system
already implemented for e.g. parsing the CLI options, rather than
implement a new one, for example ffmpeg may have an FFmpegContext
where to set all the parsed options.

And in general you need for each library a different set of options,
which are only useful in that library, I did the example of
colors/notes which would be useful only in lavfi, for example a
size/framerate option may be useful in lavf/lavc.

FFmpeg = Fierce and Fundamentalist Mortal Plastic Elitist Gospel

More information about the ffmpeg-devel mailing list