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

[Andrew Sayers]

On Tue, Apr 23, 2024 at 07:52:49PM +0100, Andrew Sayers wrote:
> On Tue, Apr 23, 2024 at 10:28:38AM -0700, Vittorio Giovara wrote:
> > On Tue, Apr 23, 2024 at 4:55 AM Andrew Sayers <ffmpeg-devel at pileofstuff.org>
> > wrote:
> > 
> > > 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.
> > 
> > 
> > Out of curiosity, what are those edge cases?
> 
> It's really more a question of how to recover from the thing you didn't think
> of, which makes it hard to think of good examples ;)
> 
> But since you ask, it might be worth looking at SANE option descriptors[0].
> They perform a very similar function to AVOptions (providing a flexible
> configuration API for a C codebase), and have a 90% overlap in features.  But
> for example, SANE doesn't have an equivalent of AVRational, while AVOptions
> doesn't have an equivalent of option groups.  More importantly, some things are
> technically compatible but perform unobviously different jobs, like how SANE's
> "description" text seems to do the same as FFmpeg's "help" text, but if memory
> serves descriptions are usually several paragraphs while help is usually a
> sentence or two.  It would waste a lot of time if I coded up a whole program
> only to discover the SANE config screen had nicely-grouped options with
> novel-length tooltips, while the FFmpeg config screen had a flat list of
> well-described options that would have looked good if I'd picked an interface
> with a search bar.
> 
> In a situation like that, it would be very helpful to know that FFmpeg's
> position is "have a go and send us a patch if it works" rather than e.g. "we
> never got round to making that private" or "we're in the middle of spinning
> that off as a standalone library".  I'll have a think overnight and submit an
> updated patch tomorrow based on everyone's feedback (thanks!).
> 
> [0] http://www.sane-project.org/html/doc011.html#s4.2.9

At the risk of further complicating a conversation that's already drifting
off-topic, a better example might be Video4Linux2 configuration.  Not only does
it have data types unsupported by AVOptions (like "menu"), but also does things
like making some options constant depending on the value of others (e.g. you
can't change the frame rate if you've selected "automatic frame rate").  A
quick look at v4l2_m2m_enc.c suggests that FFmpeg has decided to just put up
with limited configurability, rather than do something crazy like dynamically
allocate new AVClasses at runtime.  That's a limitation I'd need to know about
if I made a chat app, but also a guarantee that helps me understand how
AVOptions works.

Looping back to a point from before, I can work with either answer, the value
is simply in *having* an answer.