-
Andreas Rheinhardt authored
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(). Reviewed-by:
Anton Khirnov <anton@khirnov.net> Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
4e1fee40