[FFmpeg-devel] Extending AVOption system

[Stefano Sabatini]

On date Monday 2008-06-09 17:06:55 +0200, Michael Niedermayer encoded:
> 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:
> > > > 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,

And still so we're requesting that:
1) AVClass.option array has to be sorted
2) AVClass.option_count has to contain a "len" option

With this option we save a minor bump for the introduction of
option_count, not the major bump, also we're complicating the
interface.

Ignore this message if I'm misunderstanding something very trivial,
I'll notice it later ;-).

Regards.
-- 
FFmpeg = Fast and Fucking MultiPurpose Exploitable Gorilla