[FFmpeg-devel] [RFC] New option system

[Michael Niedermayer]

On Sun, Jul 12, 2009 at 11:06:32PM +0200, Stefano Sabatini wrote:
> 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)

This does sound acceptable t first sight ...



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

my oppinion ATM is pretty much that refering to any output in an
expression leads to undefined behavior.
Iam not convinced that this has any disadvantages

that said iam not against maintining the order but only as long as
it does not have disadvantages like code complexity or such

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- 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/20090713/100f831e/attachment.pgp>