FFmpeg

103883 Commits

37 Branches

400 Tags

484 MiB

Tag: Branch: Tree: 5eafbf0b08

Commit Graph

Author	SHA1	Message	Date
Andreas Rheinhardt	a247ac640d	avcodec: Constify AVCodecs Given that the AVCodec.next pointer has now been removed, most of the AVCodecs are not modified at all any more and can therefore be made const (as this patch does); the only exceptions are the very few codecs for external libraries that have a init_static_data callback. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>	4 years ago
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	6 years ago

Author

SHA1

Message

Date

Andreas Rheinhardt

a247ac640d

avcodec: Constify AVCodecs

Given that the AVCodec.next pointer has now been removed, most of the
AVCodecs are not modified at all any more and can therefore be made
const (as this patch does); the only exceptions are the very few codecs
for external libraries that have a init_static_data callback.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

4 years ago

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

6 years ago

3 Commits (5eafbf0b087034771c680f15c6f43608dab5422e)