[FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[James Almer]

On 4/23/2024 5:53 PM, Michael Niedermayer wrote:
> On Tue, Apr 23, 2024 at 05:24:03PM -0300, James Almer wrote:
>> On 4/23/2024 8:15 AM, Michael Niedermayer wrote:
>>> On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
>>>> On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
>>>>> Quoting Andrew Sayers (2024-04-23 11:51:00)
>>>>>> On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
>>>>>>>> lavu/opt: Clarify that AVOptions is not indended for general use
>>>>>>>
>>>>>>> They _are_ intended for general use though.
>>>>>>
>>>>>> In that case I'm confused...
>>>>>>
>>>>>> Let's say I make a desktop app to transcode videos.  Obviously I would use
>>>>>> AVOptions to display configuration options for different encoders.  And it's
>>>>>> possible to create AVOptions objects for my UI.  But how strongly is that use
>>>>>> case recommended?
>>>>>>
>>>>>> To provide a particularly difficult example - let's say I want to let the user
>>>>>> choose between interface themes, and I want to show both some text and a
>>>>>> picture of the theme.  AVOption doesn't include a "text + picture" option,
>>>>>> so how would I extend it to meet my needs?
>>>>>
>>>>> If they fit your use case, then use them, otherwise don't - that's true
>>>>> for pretty much all APIs we provide.
>>>>
>>>> Ah ok, so how about if I changed "intended" to "optimized" in the subject?
>>>
>>> If FFmpeg which is a multimedia tool in no place needs or wants to store
>>> pictures through its option API in a way not curently supported.
>>> I would say thats not going to qualify as "general use" outside specialized
>>> software thats already dealing with a lot of pictures
>>>
>>> still you certainly can handle binary data (like a bitmap picture) through
>>> AVOption
>>>
>>> thx
>>
>> Take for example AVIAMFReconGain.recon_gain in libavutil/iamf.h, which is
>> currently the only field not covered by an AVOption (And thus not currently
>> configurable from the CLI). How could it be supported? Binary type doesn't
>> work because it expects a pointer + size field and allocates the former.
> 
> i would guess some form of AV_OPT_TYPE_FLAG_ARRAY
> 
> we have similar arrays like intra_matrix in mpeg codecs

Same situation it seems, it expects a pointer + size field.