On Wed, Jun 05, 2024 at 09:46:16AM -0400, Ronald S. Bultje wrote: > Hi, > > On Wed, Jun 5, 2024 at 9:44 AM Andrew Sayers <ffmpeg-de...@pileofstuff.org> > wrote: > > > On Wed, Jun 05, 2024 at 03:34:50PM +0200, Paul B Mahol wrote: > > > On Wed, Jun 5, 2024 at 3:18 PM Andrew Sayers < > > ffmpeg-de...@pileofstuff.org> > > > wrote: > > > > > > > An external API developer might think they can use AVOptions to modify > > > > values > > > > during playback (e.g. putting a playback quality slider next to the > > volume > > > > slider). Make it clear that behaviour is not recommended. > > > > > > > > > > There are options that can be changed at runtime, > > > And it works just fine. > > > > How would an external developer know which options can be safely changed > > (preferably including in future versions of FFmpeg) vs. ones where their > > tests > > got lucky and happened not to trigger a read during a non-atomic write? > > > > If you see that happening, it would be good to submit a bug report. Right > now it's very abstract.
I think we might be talking past each other - here's a concrete example: The private struct "SetTSContext" includes an AVOptions-accessible member "time_base", currently implemented as an AVRational (i.e. a pair of ints). write_number() in libavutil/opt.c sets options of type AV_OPT_TYPE_RATIONAL in such a way that a poorly-timed read could see the new numerator and old denominator (or the other way around). If I wrote a program that let users dynamically change the time base, and someone switched their timebase from 1/30 to 100/3000, one unlucky user might have a few frames encoded with a timebase of 100/30. Is that something the AVOptions API is supposed to support? If yes, the bug is that AVOptions access isn't guarded by a mutex. If no, there's no bug, just an edge case worth mentioning in the docs. _______________________________________________ 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".
