[FFmpeg-devel] Extending AVOption system

[Michael Niedermayer]

On Sun, Jun 08, 2008 at 10:38:31AM +0200, Stefano Sabatini wrote:
> On date Saturday 2008-06-07 15:12:37 +0200, Michael Niedermayer encoded:
> > On Sat, Jun 07, 2008 at 11:18:08AM +0100, Robert Swain wrote:
> > > 2008/6/7 Michael Niedermayer <michaelni at gmx.at>:
> > > > On Fri, Jun 06, 2008 at 07:25:24PM -0700, Baptiste Coudurier wrote:
> > > > [...]
> > > >> 2) adding a way to override AVOptions range for qmax etc.. which needs
> > > >> to be hardcoded because user has no business saying that qmax max value
> > > >> for mpeg-2 is 7821637.
> > > >
> > > > true
> > > >
> > > >
> > > >> Mainly because bumping default max value to 1024
> > > >> would require every codec supporting qmax to check if value is valid.
> > > >
> > > > I see the problem, i dont know which solution is best but
> > > >
> > > > qmax in mpeg2 depends on the use of non linear quantizer IIRC (unless i
> > > > have the place of where the max is applied wrong ...)
> > > > then most options depend on the profile & level, some might depend on
> > > > the pixelformat 420 vs. 422 vs. 444
> > > >
> > > > So simple per codec ranges are not enough at all ...
> > > 
> > > Indeed. Possibly even more flexibility is needed. For the x264
> > > defaults, some values depend on other values if they are to match the
> > > x264 CLI. We may not do this but, for example, rate tolerance in x264
> > > is expressed as a multiplier of the bit rate I think and by default it
> > > is set to 1.0. To imitate that behaviour in FFmpeg one has to set -bt
> > > equal to the specified bit rate (if there is one). I don't think this
> > > can be done in your presets code, can it?
> > 
> > No, but if one would continue stefanos idea of improving av_get_string()
> > (the stuff about hash tables and making all values available to eval)
> > then one could write
> > bt=b
> > 
> > or even much more complex expressions bt=sin(b)+cos(sample_rate)^2  ...
> > 
> > The only real problem is that stefanos idea was lacking a simple and
> > practical implementation.
> > Basically we need a fast and efficient way to make all the values
> > from a struct and the AVOption constants available to eval() and that
> > has to be alot faster than iterating over them once. It can surely be
> > done, if someone volunteers to do the work i can think about how it
> > can be done ...
> 
> I'm interested, if you can elaborate more on this I can try to
> implement it as time permits. If it can help I have already a naive
> implementation of an hash container (which I'm going to post anyway on
> the libavutil hash container thread).

Get these darn hash tables out of your mind, they wont do any good here :)
Ok heres a design suggestion, in no particular order:

1. Sort all AVOption table entries by name. (diego will love this as well)

2. in av_set_string() go over the string and look up all [a-z_]* via bsearch()
   in the avoptions array.
     for each replace the string by the literal numeric value of the constant
     from the AVOptions array, value from the struct or min/max/default of
     the current option.
     After that handle the string as it is currently.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
-------------- 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/20080608/361e1aa0/attachment.pgp>