[FFmpeg-devel] Extending AVOption system

[Michael Niedermayer]

On Mon, Jun 09, 2008 at 04:45:05PM +0200, Stefano Sabatini wrote:
> On date Sunday 2008-06-08 21:17:51 +0200, Michael Niedermayer encoded:
> > On Sun, Jun 08, 2008 at 07:53:07PM +0200, Stefano Sabatini wrote:
> > > On date Sunday 2008-06-08 15:40:01 +0200, Michael Niedermayer encoded:
> > > > 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:
> > > [...]
> > > > > > 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, eventual applications which work with non sorted arrays
> > > won't work anymore with bsearch(), so I have to provide all the required
> > > ifdeffery to keep backward compatibility, right?
> > 
> > hmm, who is using AVOptions arrays outside lav* ?
> 
> Who can say? Anyway since we're indeed breaking backward compatibility
> a major bump seems anyway the right thing to do (again: I can also
> live without such a major bump if you prefer like this, just making my
> point clear).
> 
> Rethinking at it the major bump would be required in libavutil, since
> we're requesting at some point these two things:
> 1) AVClass.option array has to be sorted
> 2) AVClass.option_count has to be correctly specified
> 
> If this is not true then the behaviour of the function which deal with
> AVClass is undefined.

Just store the length in the first entry of the AVOption array. No change
to AVClass no version bumps. And the length is where the corresponding array
is.
{" len", NULL, <array size>, FF_OPT_TYPE_CONST,

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- 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/20080609/bbea2fba/attachment.pgp>