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

[Michael Niedermayer]

On Tue, Apr 23, 2024 at 06:23:04PM -0300, James Almer wrote:
> 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.

So someone needs to add support for a fixed size or
dim size0,size1,sizeDIM

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240423/9b67c157/attachment.sig>