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

[James Almer]

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.