Fixes a decoding regression introduced by e9a2a87773, and as a side effect also
fixes bogus values set to certain audio frames that had some samples discarded,
where the offsets added to pts, pkt_dts and pkt_duration were not reflected in
best_effort_timestamp.
Signed-off-by: James Almer <jamrial@gmail.com>
Up until now, the SpeedHQ encoder called a wrong function for init:
void ff_init_uni_ac_vlc(const uint8_t huff_size_ac[256],
uint8_t *uni_ac_vlc_len);
Yet the first argument actually used is of type RLTable; the size of
said struct is less than 256 if the size of a pointer is four, leading
to an access beyond the end of the RLTable.
This commit fixes this by calling the actually intended function:
init_uni_ac_vlc() from mpeg12enc.c. It was intended to use this
function [1], yet doing so was forgotten when the patch was actually
applied.
[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-July/266187.html
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The decoders in this set either have a fixed channel count, or read it
from the bitstream, and thus do not require the channel count as
external information.
Fixes various regressions since
81503ac58a, which requires a valid channel
count for decoders which do not set this capability.
Signed-off-by: Hendrik Leppkes <h.leppkes@gmail.com>
SMVJPEG stores frames as slices of a big JPEG image. The decoder is
implemented as a wrapper that instantiates a full internal MJPEG
decoder, then forwards the decoded frames with offset data pointers.
This is unnecessarily complex and fragile, not supporting useful decoder
capabilities like direct rendering.
Re-implement the decoder inside the MJPEG decoder, which is accomplished
by returning each decoded frame multiple times, setting cropping
information appropriately on each instance.
One peculiar aspect of the previous design is that since
- the smvjpeg decoder returns one frame per input packet
- there are multiple frames in each packets (the aformentioned slices)
the demuxer needs to return each packet multiple times.
This is now also eliminated - the demuxer now returns each packet
exactly once, with the duration set to the number of frames it decodes
to.
This also removes one of the last remaining internal uses of the old
video decoding API.
following comandline will crash the ffmpeg
ffmpeg -threads 17 -thread_type slice -i WPP_A_ericsson_MAIN_2.bit out.yuv -y
the HEVCContext->sList size is MAX_NB_THREADS(16), any > 16 thread number will crash the application
Signed-off-by: Anton Khirnov <anton@khirnov.net>
ff_snow_common_init() currently initializes static data every time it is
invoked; given that both the Snow encoder and decoder have the
FF_CODEC_CAP_INIT_THREADSAFE flag set, this can lead to data races (and
therefore undefined behaviour) even though all threads write the same
values. This commit fixes this by using ff_thread_once() for the
initializations.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Monochrome encoding with libaom was buggy for a long time, but this was
finally sorted out in libaom 2.0.1 (2.0.0 is almost there but was still
buggy in realtime mode).
We'll keep support for libaom 1.x around until the LTS distros that
include it are EOL (which is still a long time from now).
Fixes: https://trac.ffmpeg.org/ticket/7599
By switching from ff_init_vlc_sparse() to ff_init_vlc_from_lengths() one
can replace a table of codes of type uint16_t by a table of symbols of
type uint8_t, saving space.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Commit 1a29804558 guarded several
initializations of static data in the AAC decoders with an AVOnce and
set the FF_CODEC_CAP_INIT_THREADSAFE flag, believing the former to be
sufficient for the latter. It wasn't, because several of these static
tables are shared with other components, so that there might be data
races if they are initialized from multiple threads. This affected
initializing the ff_sine_* tables as well as initializing the
ff_aac_pow*sf_tab tables (shared between both decoders and encoder) as
well as ff_aac_kbd_* tables (shared between encoder and floating point
decoder).
Commit 3d62e7a30f set the
FF_CODEC_CAP_INIT_THREADSAFE flag for the AAC encoder. More explicitly,
this commit used the same AVOnce to guard initializing ff_aac_pow*sf_tab
in the encoder and to guard initializing the static data of each
decoder; the ensuing catastrophe was "fixed" in commit
ec0719264c by using a single AVOnce
for each codec again. But the codec cap has not been removed and
therefore the encoder claimed to be init-threadsafe, but wasn't, because
of the same tables as above.
The ff_sine_* tables as well as ff_aac_pow*sf_tab tables have already
been fixed; this commit deals with the ff_aac_kbd_* tables, making the
encoder as well as the floating-point decoder init-threadsafe (the
fixed-point decoder is it already).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The floating point kbd tables for 120 and 960 samples are only used by
the floating point decoder whereas the fixed point kbd tables for 128
and 1024 samples are only used by the fixed point AAC decoder. So move
these tables to their only users. This ensures that they are not
accidentally used somewhere else without ensuring that initializing
these tables stays thread-safe (as it is now because the only place from
where they are initialized is guarded by an AVOnce).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
