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

From: Andrew Sayers <ffmpeg-devel@pileofstuff.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] lavu/opt: Mention that AVOptions is not reentrant
Date: Wed, 5 Jun 2024 15:22:55 +0100
Message-ID: <ZmB0vyStERppJ-GA@andrews-2024-laptop.sayers> (raw)
In-Reply-To: <CAEEMt2=YnuKdO6J1Jsr_fSNbBKDS-BVPB24Htyv9JsFEgQPmbg@mail.gmail.com>

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.
_______________________________________________
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".