Re: [FFmpeg-devel] [PATCH] lavu/opt: Mention that AVOptions is not reentrant

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 2617 bytes --]

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-devel@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-devel@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


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".