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

[Andrew Sayers]

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 at 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 at 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.