On Wed, May 29, 2024 at 01:06:30PM +0200, Paul B Mahol wrote: > On Wed, May 29, 2024 at 12:50 PM Andrew Sayers <ffmpeg-de...@pileofstuff.org> > wrote: > [...] > > *Are AVOptions just command-line options?* > > > > I have trouble with statements like "AVOptions is a framework for options", > > both because it's circular and because the term "option" is too broad to be > > meaningful. > > > > I've previously pushed the word "reflection" on the assumption that options > > can be used anywhere variables are used. For example, imagine a decoder > > that > > could be reconfigured on-the-fly to reduce CPU usage at the cost of > > displaying > > blurier images. That can't be part of the public interface because it's > > codec-specific, but I could imagine updating some kind of "output_quality" > > AVOption as a user slides a slider up and down. > > > > But the CLI tools are largely non-interactive, so have I just > > misunderstood? > > > > How about saying "AVOptions is a framework for command-line options"? > > > > ffmpeg is cli tool > > libavfilter is library > > AVOptions is certainly and primarily not framework for command-line options.
"Command-line option" might be the wrong word, but I've just checked write_number() in libavutil/opt.c, and it seems to do non-atomic updates without locking anything. That suggests I was indeed wrong to think it could be used on-the-fly - maybe "initial configuration options" would be a better term? Possibly with a warning somewhere about how AVOptions is not reentrant? _______________________________________________ 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".