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.rheinha...@gmail.com> > --- > libavcodec/avrndec.c | 2 +- > libavcodec/imm5.c | 4 ++-- > libavcodec/tdsc.c | 2 +- > 3 files changed, 4 insertions(+), 4 deletions(-)
ok -- Anton Khirnov _______________________________________________ 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".
