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

[Andrew Sayers]

On Tue, Apr 23, 2024 at 01:18:28PM +0200, Michael Niedermayer wrote:
> On Tue, Apr 23, 2024 at 01:15:52PM +0200, 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
> 
> And if you disagree, which you probably do :)
> send a patch to improve AVOption to cover more general use

Not sure if that's aimed at the real me, or the hypothetical me that wants to
make a desktop app.  The hypothetical me wants not to throw away a week's work
because he did everything through AVOptions then came across some edge case
that doesn't fit into the AVOptions model.  The real me doesn't want to throw
away a week's work because I avoided AVOptions then found some bit of interface
that needs me to express my program in an AVOptions-compatible way.  Neither of
us mind what the answer is, so long as it's written down somewhere we would
spot during the design stage.

It sounds like the consensus is that people are *allowed* to implement their
own AVOption interfaces if they want to, but that there's no expectation for
them to do so unless they're working on FFmpeg itself.  That suggests the body
of the patch is fine, but the subject needs improvement?

How about 'Clarify that "Implementing AVOptions" is addressed to people working
on FFmpeg itself'?