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

Lukasz M lukasz.m.luki at gmail.com
Wed Feb 26 13:55:53 CET 2014


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.


More information about the ffmpeg-devel mailing list