Re: [FFmpeg-devel] [PATCH] avutil/opt: add AV_OPT_FLAG_FORCE_CONST

[Timo Rothenpieler <timo@rothenpieler.org>]

On 16/04/2024 02:07, Michael Niedermayer wrote:
> On Sun, Apr 14, 2024 at 10:35:57PM +0200, Timo Rothenpieler wrote:
>> On 14.04.2024 22:30, Marton Balint wrote:
>>>
>>>
>>> On Sun, 14 Apr 2024, Timo Rothenpieler wrote:
>>>
>>>> ---
>>>> doc/APIchanges      |  3 +++
>>>> libavutil/opt.c     | 14 ++++++++++++++
>>>> libavutil/opt.h     |  5 +++++
>>>> libavutil/version.h |  2 +-
>>>> 4 files changed, 23 insertions(+), 1 deletion(-)
>>>
>>> Where do you intend to use this flag? So some justification or
>>> description of your plans is missing from the commit message.
>>
>> Some options in nvenc could be greatly simplified with it, where right now
>> there's multiple if/switch-trees in the code, just to weed out invalid
>> values.
> 
> This doesnt feel right.
> 
> The code would need to validate the actual value the same way it
> checks min/max at least
> 
> avoptions allows the user to obtain a parameters address and set
> it directly as well as set it without any AVOption
> 
> iam still not sure thats a good idea.
> Why are the values not in a continous sequence of integers that can
> be checked with min/max ?

Cause they're simply not, gotta ask Nvidia for details.
They started having enums with holes in them all over the place.

This flag obviously cannot be used for pre-existing options where users 
got accustomed to using various values.
And there also needs to be validation of valid values nevertheless, due 
to the possibility of API clients setting the values directly.

But this behaviour of only accepting the named constants from users, and 
no arbitrary values, is exactly what I'd like to achieve.

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".