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

Lukasz Marek lukasz.m.luki at gmail.com
Fri Feb 28 02:59:41 CET 2014


On 26.02.2014 17:22, Michael Niedermayer wrote:
> 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

I promise it is the last one. No more from me for this thread unless you 
decide what you want :P


-- 
Best Regards,
Lukasz Marek

You can avoid reality, but you cannot avoid the consequences of avoiding 
reality. - Ayn Rand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-lavu-opt-extend-AVOptionRange-by-extra-values.patch
Type: text/x-patch
Size: 1538 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140228/b3c1ab81/attachment.bin>


More information about the ffmpeg-devel mailing list