FFmpeg

100385 Commits

37 Branches

400 Tags

474 MiB

Tag: Branch: Tree: 36237ac4ee

Commit Graph

Author	SHA1	Message	Date
Andreas Rheinhardt	4e1fee405f	avcodec: Fix invalid uses of ff_codec_open2_recursive() 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>	4 years ago
Paul B Mahol	7c0b3ba7dd	avcodec: add IMM5 decoder	5 years ago

Author

SHA1

Message

Date

Andreas Rheinhardt

4e1fee405f

avcodec: Fix invalid uses of ff_codec_open2_recursive()

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>

4 years ago

Paul B Mahol

7c0b3ba7dd

avcodec: add IMM5 decoder

5 years ago

2 Commits (36237ac4ee874452dd1d8d7439a224a371759ea0)