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

[Michael Niedermayer]

On Tue, Apr 23, 2024 at 12:54:53PM +0100, Andrew Sayers wrote:
> 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'?

I think the way i would put it is:
AVOption is intended for general use.
If you have a use case that it cannot be used for, a clean patch to improve it is welcome.

What i do not like is, taking a limitation (noone seems to have hit before)
and documenting it as if it was intended.

thx

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- 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/5ae19001/attachment.sig>