From: Marton Balint <cus@passwd.hu>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 15/38] lavu/opt: add array options
Date: Sun, 3 Mar 2024 22:05:02 +0100 (CET)
Message-ID: <bb350545-f00c-fbf9-699b-e4d4f919eaf3@passwd.hu> (raw)
In-Reply-To: <4d1c66e3-2418-458f-b6b0-6b3ec5328821@gmail.com>
On Sun, 3 Mar 2024, James Almer wrote:
> On 3/3/2024 12:53 PM, Diederick C. Niehorster wrote:
>> On Sun, Mar 3, 2024 at 3:55 PM Anton Khirnov <anton@khirnov.net> wrote:
>>
>>> Quoting Marton Balint (2024-02-26 20:38:46)
>>>> The more I think about it, it is actually a broader problem.
>>>>
>>>> You are changing the semantics of existing AV_OPT_TYPE_xxx types. So
>>>> previously an option with AV_OPT_TYPE_STRING used to have default value
>>> in
>>>> default_val.str. After your patch, it will be either default_val.str, or
>>>> default_val.str[1], based on if it is an array or not.
>>>>
>>>> I think the API user safely assumed that if the option type is known to
>>>> him, he will always find the default value in the relevant default_val
>>>> field. It is actually a bigger issue for an array of AV_OPT_TYPE_INT,
>>>> because previously to get the default value AVOption->default_val.i64
>>> was
>>>> used, and now .str[1] should be instead...
>>>
>>> In my view the semantics of default_val (and offset) are only defined
>>> when declaring options on your own object, not when accessing those
>>> fields when declared by some other code. I also see no good reason for
>>> any user to read these fields.
>>>
>>
>> I disagree. Here an example: for a GUI using some part of ffmpeg and
>> wanting to give the user some control over the ffmpeg operation, it would
>> not be strange to be able to set options and either indicate which values
>> are default, or have a "reset to defaults" button. I have written such a
>> thing (not yet opensourced).
>
> There's av_opt_set_defaults() to set default values, then
> av_opt_is_set_to_default() and av_opt_is_set_to_default_by_name() to check if
> an option is already set to the default value.
>
> What Anton said is that the user has no need to access the fields directly
> when there are helpers explicitly documented for this purpose.
The AVOption struct is public, and the default_val field is public too.
There is nothing that warns the user not to access it. The fact that there
are helper functions does not change this.
But it is not the default values that is a problem. The semantic change is
the problem. I could have had a code which iterates through every AVOption
of an object and prints the values with type AV_OPT_TYPE_INT. Your change
will suddently break that, because arrays will also have the type of
AV_OPT_TYPE_INT.
So can you please introduce a new option type for arrays?
Thanks,
Marton
_______________________________________________
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".
next prev parent reply other threads:[~2024-03-03 21:05 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-23 13:58 [FFmpeg-devel] [PATCH] array AVOptions and side data preference Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 01/38] lavu/opt: cosmetics, change option flags to (1 << N) style Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 02/38] lavu/opt: cosmetics, move AV_OPT_FLAG_* out of AVOption Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 03/38] lavu/opt: document AVOption.flags Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 04/38] lavu/opt: cosmetics, group (un)init and management functions together Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 05/38] lavu/opt: cosmetics, group option setting function together Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 06/38] lavu/opt: cosmetics, group option reading " Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 07/38] lavu/opt: simplify printing option type in opt_list() Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 08/38] lavu/opt: factor out printing option default from opt_list() Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 09/38] lavu/opt: drop useless handling of NULL return from get_bool_name() Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 10/38] lavu/opt: drop an always-NULL argument to get_number() Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 11/38] lavu/opt: simplify error handling in get_number() Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 12/38] lavu/opt: get rid of useless read_number() calls Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 13/38] lavu/opt: factor per-type dispatch out of av_opt_get() Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 14/38] lavu/opt: factor per-type dispatch out of av_opt_set() Anton Khirnov
2024-02-23 22:50 ` Michael Niedermayer
2024-02-24 22:41 ` James Almer
2024-03-05 23:08 ` Michael Niedermayer
2024-03-05 23:14 ` James Almer
2024-03-01 16:07 ` Anton Khirnov
2024-03-03 12:17 ` Anton Khirnov
2024-03-05 23:12 ` Michael Niedermayer
2024-03-05 23:21 ` James Almer
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 15/38] lavu/opt: add array options Anton Khirnov
2024-02-23 19:05 ` Marton Balint
2024-02-26 17:14 ` Anton Khirnov
2024-02-26 17:19 ` James Almer
2024-02-26 17:20 ` Andreas Rheinhardt
2024-02-26 19:38 ` Marton Balint
2024-03-03 14:55 ` Anton Khirnov
2024-03-03 15:53 ` Diederick C. Niehorster
2024-03-03 15:57 ` James Almer
2024-03-03 21:05 ` Marton Balint [this message]
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 16/38] lavc: add a decoder option for configuring side data preference Anton Khirnov
2024-02-23 17:51 ` Marton Balint
2024-02-23 17:53 ` James Almer
2024-02-23 18:34 ` James Almer
2024-02-26 17:08 ` Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 17/38] avcodec: add internal side data wrappers Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 18/38] lavc: add content light/mastering display " Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 19/38] avcodec/av1dec: respect side data preference Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 20/38] avcodec/cri: " Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 21/38] avcodec/h264_slice: " Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 22/38] lavc/hevcdec: pass an actual codec context to ff_h2645_sei_to_frame() Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 23/38] avcodec/hevcdec: respect side data preference Anton Khirnov
2024-02-23 19:11 ` Marton Balint
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 24/38] avcodec/libjxldec: " Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 25/38] avcodec/mjpegdec: " Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 26/38] avcodec/mpeg12dec: " Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 27/38] avcodec/pngdec: " Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 28/38] avcodec/tiff: " Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 29/38] avcodec/webp: " Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 30/38] avcodec/libdav1d: " Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 31/38] avcodec/dpx: " Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 32/38] avcodec/mpeg12dec: use ff_frame_new_side_data Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 33/38] avcodec/h2645_sei: use ff_frame_new_side_data_from_buf Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 34/38] avcodec/snowdec: use ff_frame_new_side_data Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 35/38] avcodec/mjpegdec: " Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 36/38] avcodec/hevcdec: switch to ff_frame_new_side_data_from_buf Anton Khirnov
2024-02-23 13:58 ` [FFmpeg-devel] [PATCH 37/38] lavc/*dec: use side data preference for mastering display/content light metadata Anton Khirnov
2024-02-23 13:59 ` [FFmpeg-devel] [PATCH 38/38] tests/fate/matroska: add tests for side data preference Anton Khirnov
2024-02-23 15:02 ` Anton Khirnov
2024-02-23 15:08 ` James Almer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bb350545-f00c-fbf9-699b-e4d4f919eaf3@passwd.hu \
--to=cus@passwd.hu \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git