[FFmpeg-devel] [PATCH 37/45] avcodec: Fix invalid uses of ff_codec_open2_recursive()

Anton Khirnov anton at khirnov.net
Fri Dec 4 14:07:46 EET 2020


Quoting Andreas Rheinhardt (2020-11-27 02:02:41)
> Normally no two codecs with FF_CODEC_CAP_INIT_THREADSAFE unset
> can be initialized at the same time: a mutex in avcodec_open2()
> ensures this. This implies that one cannot simply open a codec
> with a non-threadsafe init-function from the init function of
> a codec whose own init function is not threadsafe either as the child
> codec couldn't acquire the lock.
> 
> ff_codec_open2_recursive() exists to get around this limitation:
> If the init function of the child codec to be initialized is not
> thread-safe, the mutex is unlocked, the child is initialized and
> the mutex is locked again. This of course has as a prerequisite that
> the parent AVCodecContext actually holds the lock, i.e. that the
> parent codec's init function is not thread-safe. If it is, then one
> can (and has to) just use avcodec_open2() directly (if the child's
> init function is not thread-safe, then avcodec_open2() will have to
> acquire the mutex itself (and potentially wait for it), so that it is
> perfectly fine for an otherwise thread-safe init function to open
> a codec with a potentially non-thread-safe init function via
> avcodec_open2()).
> 
> Yet several of the users of ff_codec_open2_recursive() have the
> FF_CODEC_CAP_INIT_THREADSAFE flag set; this only worked because
> all the child codecs' init functions were thread-safe themselves
> so that ff_codec_open2_recursive() didn't touch the mutex at all.
> But of course the real solution to this is to directly use
> avcodec_open2().
> 
> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt at gmail.com>
> ---
>  libavcodec/avrndec.c | 2 +-
>  libavcodec/imm5.c    | 4 ++--
>  libavcodec/tdsc.c    | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)

ok

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list