[FFmpeg-devel] [PATCH 4/8] lavu/opt: extend AVOptionRange by second value

Michael Niedermayer michaelni at gmx.at
Wed Feb 26 17:22:47 CET 2014

On Wed, Feb 26, 2014 at 01:55:53PM +0100, Lukasz M wrote:
> On 26 February 2014 12:41, Nicolas George <george at nsup.org> wrote:
> > L'octidi 8 ventôse, an CCXXII, Lukasz M a écrit :
> > > Hmm, I treated it a bit different, but I think your proposition is
> > correct.
> > > So for example for size opt value would be number of pixels. components
> > > would define ranges of width and height?
> >
> > Maybe I missed something, but I suspect you should completely ignore the
> > component_min/max part.
> >
> I'm not sure how it is supposed to be extended.
> It was a question to Michael, because it is not clear and both options make
> sense - depending how you interpret them.
> But my first guess was also to ignore component part
> > > I share your opinion. But technically this is api break. At major bump
> > > extra_value_min can be removed and value_min/max can be array as in my
> > > first patch.
> > > On the other hand I believe in practice it would be better to change it
> > > now. I doubt query_ranges is commonly used so far outside ffmpeg. When
> > dev
> > > cap api starts relying on it, users may start to use it more.
> >
> > Is there really a benefit in having a real array, i.e. being able to handle
> > both values at once? If not, you could just add value2_min/max and be done
> > with it. That has the advantage of not polluting the normal code with
> > "[0]".
> >
> OK, I can change it this way.

> > Also, is it worth the complexity? IIRC, you did not respond to the option
> > of
> > leaving width and height separate, and just set width to get the
> > corresponding heights.
> >
> No, I haven't. Old version would work as you described (query width, set
> width, query height),
> Michael gave a hints about extending AVOptionRange struct and I think it is
> better than previous solution.
> From client point of view it seems to have less complexity.

yes, i think keeping the client complexity in mind is important as
one developer had complained about the API

the alternative to changing AVOptionRange would possibly be to add
a function which can take 2 or more AVOptions and returns a list of
their allowed values or value ranges
This function would then querry the "One component" style API
to create a list of allowed pairs/pair ranges

That could then also be used to create widthxheight fps triplets
if these depend on each other

also i just realized that AVOptionRange probably should have a
"multiple_of" field so that for example even width can be specified
without having to specify each individual value in a list

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140226/8939671f/attachment.asc>

More information about the ffmpeg-devel mailing list