[FFmpeg-devel] [RFC] New option system

[Michael Niedermayer]

On Sun, Jul 19, 2009 at 10:12:15PM +0200, Stefano Sabatini wrote:
> 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.

this rewrite is rejected
i repeat that i see no problem with improving the existing system, and
adding handlers for various types if you want to do that.
But simply rewriting the system with no comments about why or what is
changed is unacceptable,
as is one would have to compare the proposal against what exists to find
out what is changed if some features are lost and then guess from that
why it was done like that ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Thouse who are best at talking, realize last or never when they are wrong.
-------------- 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/20090720/ad80fbe7/attachment.pgp>