[FFmpeg-devel] Extending AVOption system

[Stefano Sabatini]

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

[...]

Regards.
-- 
FFmpeg = Foolish and Freak MultiPurpose EnGine