This is easily possible because ff_init_vlc_sparse() already transforms
both LE as well as BE codes to a normal form internally before
processing them further. This will be used in subsequent commits.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It can't, because the tables used don't have any loose ends. This also
fixes a bug in the only caller of decode_dc_le(): It didn't check the
return value.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Before the LE bitstream reader was used in the Indeo 2 decoder,
a standard BE bitstream reader with swapped bits was used; when the LE
bitstream reader was added, the old code was only #ifdef'ed away and not
removed. Said code has several problems: It modifies the input packet
without ensuring that the packet is indeed writable; and it doesn't work
since 09c4e5c598 because said commit
removed the BE table used to initialize the VLC table. So just remove
this cruft from the actual decoder, too.
Also use INIT_LE_VLC_STATIC while at it.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It can't because the corresponding trees don't have any loose ends.
Removing the checks also removed an instance of av_log(NULL (with a
nonsense message) from the codebase.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It currently uses 9 bits per table, but there are no codes with
nine bits at all, while there are codes with eight, ten and eleven bits.
So reducing the table size to eight bits will not reduce the amount of
codes that can be parsed in the first step, but it allows to reduce the
size of the motion-vector VLC.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 570425356 * 6 cannot be represented in type 'int
Fixes: 25929/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5099197739827200
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Regression since: ca49476ace
Fixes: out of array write
Fixes: 25786/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_PSX_fuzzer-5704869380620288
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 872415232 * 7 cannot be represented in type 'int'
Fixes: signed integer overflow: -2013265888 + -1744830464 cannot be represented in type 'int'
Fixes: 25834/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-5471406434025472
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ccca62ef99 added new VP9 VDPAU profiles
and as a consequence AV_PIX_FMT_VDPAU can now be twice in the list of
pixel formats used for format negotiation by ff_thread_get_format(); yet
there is only one entry in said list reserved for VDPAU, leading to a
stack-buffer overflow. This commit fixes this by making sure that
AV_PIX_FMT_VDPAU will not occur twice in said list.
Fixes Coverity ticket 1468046.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The SheerVideo decoder uses two VLC tables and these are in turn created
from structures (called SheerTable) that are naturally paired. This
commit unifies these pairs of SheerTables to arrays and unifies creating
the VLC tables.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The SheerVideo decoder uses VLC tables which are currently stored in
large arrays that contain the length of each leaf of the corresponding
tree from left to right, taking 15.5KB of space. But all these arrays
follow a common pattern: First the entries are ascending and then they
are descending with lots of successive entries have the same value.
Therefore it makes sense to use a run-length encoding to store them, as
this commit does. Notice that the length 16 has to be treated specially
because there are arrays with more than 256 consecutive entries with
value 16 and because the length of the entries start to descend from
this length onward.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This has happened if the format changed midstream and if the new packet
is so small that it is instantaneously rejected: In this case the VLC
tables were for the new format, although the context says that they are
still the ones for the old format. It can also happen if the format
changed midstream and the allocation of the new tables fails. If the
next packet is a packet for the old format, the decoder thinks it
already has the correct VLC tables, leading to a segfault.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Don't needlessly copy an array around; don't create a table with
default symbols; and use smaller types to save stack space: The longest
code here is 16 bits, so one can store the codes in this type.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
Fixes: 25675/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G729_fuzzer-4786580731199488
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: left shift of negative value -4
Fixes: 25723/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TAK_fuzzer-6250580752990208
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Said escape code is only six bits long, so that one has at least 25 - 6
bits in the bitstream reader's cache after reading it; therefore the
whole following 18 bits (containing the actual code) are already in the
bitstream reader's cache, making it unnecessary to reload the cache.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
There is no need to cast const away (even if it was harmless) and to
copy the object at all.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Now that the correct number of codes is used, it is no longer necessary
to initialize the lengths of the codes at all any more as the length of
the actually used codes is set later anyway.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It is always zero; it referred to the INIT_VLC_USE_STATIC flag which has
been removed in 595324e143.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Commit bbc0d0c1fe made the mjpeg decoder
use default Huffman tables when none are given, yet when initializing
the default Huffman tables, it did not use the correct number of entries
of the arrays used to initialize the tables, but instead it used the
biggest entry + 1 (as if it were a continuous array 0..biggest entry).
This worked because the ff_init_vlc_sparse() (and its predecessors)
always skipped entries with a length of zero and the length of the
corresponding elements was always initialized to zero with only the
sizes of the actually existing elements being set to a size > 0 lateron.
Yet since commit 1249698e1b this is no
longer so, as build_vlc() actually read the array containing the values
itself. This implies that the wrong length now leads to a read beyond
the end of the given array; this could lead to crashs (but usually
doesn't); it is detectable by ASAN* and this commit fixes it.
*: AddressSanitizer: global-buffer-overflow on address xy
...
xy is located 0 bytes to the right of global variable 'avpriv_mjpeg_val_ac_luminance'
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Commit 1249698e1b made
ff_mjpeg_decode_dht() call build_vlc() with a wrong (too hight)
number of codes. The reason it worked is that the lengths of the extraneous
entries is initialized to zero and ff_init_vlc_sparse() ignores codes
with a length of zero. But using a too high number of codes was
nevertheless bad, because a) the assert in build_vlc() could have been
triggered (namely if the real amount of codes is 256) and b) the loop in
build_vlc() uses initialized data (leading to Valgrind errors [1]).
Furthermore, the old code spend CPU cycles in said loop although the
result won't be used anyway.
[1]: http://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-valgrind&time=20201008025137
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Added VDPAU to list of supported formats for VP9 420 10 and 12 bit
formats. Add VP9 10/12 Bit support for VDPAU
Signed-off-by: Philip Langdale <philipl@overt.org>
Even if such files are invalid, they can be decoded just fine.
Also stored tiles may have bigger dimensions than displayed ones,
so do not abort decoding in such cases.
av1dec should no longer attempt to output empty frames if another decoder
was used for probing and it sucessfully set a pix_fmt ever since 05872c67a4,
so we can re-add the AV_CODEC_CAP_AVOID_PROBING cap.
Signed-off-by: James Almer <jamrial@gmail.com>
The earlier code was based on the assumption that AVFrame.linesize can
not be negative.
Fixes ticket #8280.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: left shift of negative value -640
Fixes: 26044/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXTORY_fuzzer-5631057602543616
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
