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-requ...@ffmpeg.org with subject "unsubscribe".
