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-de...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
