[FFmpeg-devel] [RFC] New option system

Stefano Sabatini stefano.sabatini-lala
Sun Jul 5 19:09:35 CEST 2009

Hi all,

the new system should allow to easily extends the way options are

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

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

In attachment there is a simple proof of concept of this idea, let me
know if you are interested.

FFmpeg = Funny and Frightening Murdering Picky Enigmatic Gadget
-------------- next part --------------
A non-text attachment was scrubbed...
Name: implement-avopt2.patch
Type: text/x-diff
Size: 20884 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090705/762083ca/attachment.patch>

More information about the ffmpeg-devel mailing list