On Wed, Jun 05, 2024 at 03:22:55PM +0100, Andrew Sayers wrote: > 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.
AVOption simply provides light weight access to the struct fields. Calling AVOption non re-entrant in modifying a field you arent even allowed to modify from 2 threads is confusing If you want to modify a field from 2 threads that field could be some sort of atomic type. This can then easily be added to AVOption thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott
signature.asc
Description: PGP signature
_______________________________________________ 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".
