[FFmpeg-devel] [RFC] New option system

Michael Niedermayer michaelni
Sun Jul 12 01:52:49 CEST 2009

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

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

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- 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/20090712/ae695da8/attachment.pgp>

More information about the ffmpeg-devel mailing list