[FFmpeg-devel] [RFC] New option system

[Stefano Sabatini]

On date Sunday 2009-07-12 01:52:49 +0200, Michael Niedermayer encoded:
> On Sun, Jul 05, 2009 at 07:09:35PM +0200, Stefano Sabatini wrote:
> > Hi all,
> > 
> > the new system should allow to easily extends the way options are
> > set.
> > 
> > Indeed, with the current system is not possible for example to define
> > a custom function to fill a field (or more fields) of an AVClass
> > context.
> > 
> > For example in libavfilter I would need a custom hook function which
> > takes a string, parses it, and fills a color in the context.
> > 
> > The current technique is to get a string and copy it in the context,
> > then parse it in an init function.  This has two main disadvantages:
> > the string needs to be put in the context, when we only need to store
> > it temporarily, and we also need to repeat the code in every filter
> > that needs to do exactly the same thing.
> > 
> > Consider this other problem: filling in a context two fields
> > interpreting some expressions which are provided through some option.
> > 
> > This is currently implemented fetching the string using the AVOption
> > system and evalling the strings in an init function. In this case the
> > evaluation is done *always in the same order*, since it is defined
> > statically, so for example if we have two expressions:
> > expr1(w1, h1) -> w2, h2
> > expr2(w2, h2) -> w3, h3
> > 
> > it is not possible to make the evaluation of expr2 happen before the
> > evaluation of expr1.
> > 
> > This is relevant for example for the scale filter, when it could be
> > useful to define something like:
> > 
> > scale = out_h = 4/3 * in_h : out_w = out_h 
> > 
> > (expand by 4/3 the input height, the the output width is defined as a
> > function of the output width).
> > In this case we need the evaluation of the expressions occurr exactly
> > in the same order as they are provided by the user.
> > 
> > Also the new proposed system should make possible to define custom
> > functions locally, and include them only in the files which actually
> > need them, as opposed to the current system where the only possible
> > way to expand AVOption is to expand opt.[ch].
> > 
> > The integration of this implementation requires to move the eval.c
> > code to libavutil (if we want to keep the new opt code in lavu, as it
> > looks more sensible), and move the AVERROR code definitions to lavu as
> > well.
> > 
> > In attachment there is a simple proof of concept of this idea, let me
> > know if you are interested.
> 
> You mix so many things together here and provide one monolithic patch that
> i really cant comment much.

I'm aware, that wasn't supposed to be a patch, just a POC so I took
the lazy way ;-). I'll provide little tiny patches if we agree at
least that the current system has limitations we can't overcome if not
with a new system.

> Some of the individual parts you describe probably are a good idea, others
> seem more obscure ...
> 
> If the current (primitive) set of parsing functions is insufficient, that can
> be extended (color and whatever ...)

The problem with the current opt.[hc] is that it cannot be extended
with ad-hoc functions, for example to implement a color option we
would need to import the colorutils in libavcodec.

In order to keep opt.[hc] general and useful even outside FFmpeg we
need to make it as generic as possible, then let the application
eventually define which type of options to use and how to support
them.

For example we could have:
libavutil/opt.[hc]

then have some general purpose handlers (to set in the context options
with type int, flags, double, ratio, string):
libavutil/opt_handlers.[hc]

and for most specific functions:
libavcodec/opt_handlers[hc] (e.g. size, framerates, profiles)
libavfilter/opt_handlers.[hc] (e.g. colors, notes)

> supporting funny equations that set more than one field at a time dont seem
> like they are worth the mess.
> if you want
>     out_h = 4/3 * in_h : out_w = out_h 
> just do:
>     out_h = 4/3 * in_h : out_w = 4/3 * in_h
>
> also the second is clearer

If out_h has a rather complicated expression then the first
form would be nicer. 

Also to be able to define expressions exactly in the same order as
they are passed to the user is in general an useful feature.

Consider for example:

pad = out_h=in_h+32 : out_w=in_w*out_h/in_h

(enlarge height of 32 pixel, then enlarge width keeping the same ratio
as in input).

If we fix the order of evaluation:
out_w, out_h

the above options are not valid, since when we evaluate out_w the
value for out_h has not still been evaluated.

Regards.
-- 
FFmpeg = Friendly and Faithful Murdering Pitiless Enhanced Game