[FFmpeg-devel] [RFC] New option system

[Stefano Sabatini]

On date Monday 2009-07-13 19:27:09 +0200, Michael Niedermayer encoded:
> 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:
[...]
> > > 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

In attachment an elaboration of what I originally
proposed. Preliminary patches (move eval and error codes to lavu) have
been already posted.

I'm posting the opt.[hc] patches for letting people to comment on the
new API, while the opt_handlers.[hc] are provided for showing a
concrete example of its usage.

Regards.
-- 
FFmpeg = Foolish and Frightening Multipurpose Peaceful Extravagant Gospel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: implement-new-avopt.patch
Type: text/x-diff
Size: 10874 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090719/7d1363f2/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lavu-opt-handlers.patch
Type: text/x-diff
Size: 17038 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090719/7d1363f2/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lavfi-opt-handlers.patch
Type: text/x-diff
Size: 6027 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090719/7d1363f2/attachment-0002.patch>