It fundamentally depends on deprecated lavf internals.

Use the stream timebase instead.

Same flags as MJPEG, as it's essentially the same codec.

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: NAnton 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: NMichael Niedermayer <michael@niedermayer.cc>
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Reviewed-by: NTomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Reviewed-by: NTomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Reviewed-by: NTomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Fixes: memleak
Fixes: 27766/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-5198300814508032

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: NMichael Niedermayer <michael@niedermayer.cc>

Fixes: out of memory access
Fixes: 27787/clusterfuzz-testcase-minimized-ffmpeg_dem_RPL_fuzzer-4743666463408128.fuzz

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: NPaul B Mahol <onemda@gmail.com>
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>

Fixes: Assertion c > 0 failed at libavutil/mathematics.c
Fixes: 27001/clusterfuzz-testcase-minimized-ffmpeg_dem_VIVIDAS_fuzzer-5726041328582656
Fixes: 27453/clusterfuzz-testcase-minimized-ffmpeg_dem_VIVIDAS_fuzzer-5716060384526336

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: NMichael Niedermayer <michael@niedermayer.cc>

Fixes: out of array access
Fixes: 27424/clusterfuzz-testcase-minimized-ffmpeg_dem_VIVIDAS_fuzzer-5682070692823040

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: NMichael Niedermayer <michael@niedermayer.cc>

Signed-off-by: NJames Almer <jamrial@gmail.com>

Handles NaNs more like the official implementation handles them, preserving
the original bits.

The cropdetect filter, at present, skips the first two frames. This
behaviour is hardcoded.

New option 'skip' allows users to change this. Convenient for when
input is a single image or a trimmed video stream.

Default is kept at 2 to preserve current behaviour.

Avoids build failure when mpegvideo_enc is built but SpeedHQ encoder
isn't.

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

Do this by converting big-endian side data to little endian for
checksumming.
Reviewed-by: NAndriy Gelman <andriy.gelman@gmail.com>
Reviewed-by: NMichael Niedermayer <michael@niedermayer.cc>
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Nothing guarantees that the size of side data containing a palette
is actually divisible by four (although it should be); but for
big-endian systems, an algorithm is used that presupposed this.
So switch to an algorithm that does not overread: It processes
four bytes at a time, but only if all of them are contained in
the side data.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

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: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

This automatically makes indeo4/5 init-threadsafe.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

This automatically makes the DSD formats as well as DST and WavPack
init-threadsafe.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

There are actually only 14 elements in each ff_sine_windows array.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Commit 1a298045 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 3d62e7a3 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
ec071926 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: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: NAndreas 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: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Easy now that initializing the ff_sine_* tables is thread-safe.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Possible because ff_init_ff_sine_windows() is now threadsafe.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>