Andriy Gelman [Wed, 14 Oct 2020 04:38:22 +0000 (00:38 -0400)]
avcodec/movtextenc: fix writing to bytestream on BE arches
Fixes fate-binsub-movtextenc on PPC64
Currently tags are written in reverse order on BE arches. This is fixed
by using MKBETAG() and AV_RB32() to be arch agnostics.
Also s->font_count is of type int. On BE arches with 32bit int,
count = AV_RB16(&s->font_count) will read two most significant bytes
instead of the least significant bytes. This is fixed by assigning
s->font_count to count first.
The final change is modifying the type of len. On BE arches
the most significant byte of the int was written instead of the least
significant byte.
Fixes: signed integer overflow: 1073741827 * 8 cannot be represented in type 'int' Fixes: 25621/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-6304841641754624 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/vp9dsp_template: Fix integer overflows in idct16_1d()
Fixes: signed integer overflow: -190760 * 11585 cannot be represented in type 'int' Fixes: 25471/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP9_fuzzer-5743354917421056 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Timeout (minutes to less than 1sec) Fixes: 25682/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ANSI_fuzzer-6320712032452608 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: 29 + 2147483640 cannot be represented in type 'int' Fixes: 25413/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5697909331591168 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/mobiclip: Check that Motion vectors are within the input frame
The MV checks did not consider the width and height of the block, also they
had some off by 1 errors. This resulted in undefined behavior and crashes.
This commit instead errors out on these
Fixes: out of array read Fixes: 26080/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-5758146355920896 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/mobiclip: set the bitstream size to the input
Fixes: out of array read Fixes: 25453/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-5163575973511168 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>
Such values are not supported by ff_subtitles_queue*
Fixes: signed integer overflow: 10 - -9223372036854775808 cannot be represented in type 'long' Fixes: 24193/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5714901855895552 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/webp: Use LE VLC table for LE bitstream reader
The WebP format uses Huffman tables and the decoder therefore uses
VLC tables. Given that WebP is a LE format, a LE bitreader is used;
yet the VLC table is not created for a LE reader (the process used to
create the tables puts the last bit to be read in the lowest bit) and
therefore custom code for reading the VLCs that reverses the bits
read is used instead of get_vlc2(). This commit changes this to use
a table designed for LE bitreader which allows to use get_vlc2() directly.
The necessary reversing of the codes is delegated to
ff_init_vlc_sparse() (and is therefore only done during init and not
when actually reading the VLCs).
Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/vlc, bitstream: Allow to use BE codes to initialize LE VLC
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>
avcodec/speedhq: Don't pretend reading DC can fail
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 09c4e5c5988c0037d108c5fc2a137d9ad488f7f4 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 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>
avcodec/adpcm: Check block align for AV_CODEC_ID_ADPCM_PSX
Regression since: ca49476ace90ddebc5f92d9d82297f77e528c21e 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>
Justin Ruggles [Fri, 2 Oct 2020 12:51:19 +0000 (08:51 -0400)]
Allow using only the mfra info for seeking using the fragment index
The mfra has enough information to enable seeking, and reading it is
behind an AVOption flag, so we shouldn't require that sidx information
also be present in order to seek using the fragment index.
avcodec/vp9: Fix stack-buffer overflow with VP9 VDPAU available
ccca62ef991f0a47dfa30c3e822d91294b8afe4c 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.
avcodec/sheervideo: Avoid code duplication when creating VLC tables
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>
avcodec/sheervideo: Reduce the size of static arrays
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>
avcodec/sheervideo: Don't leave context in inconsistent state upon error
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>
avcodec/celp_filters: Avoid invalid negation in ff_celp_lp_synthesis_filter()
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>
avcodec/takdsp: Fix negative shift in decorrelate_sf()
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>
avcodec/mpeg12dec: Optimize reading mpeg2 intra escape codes
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>
avformat/aviobuf: increase default read buffer size to 2*max_buffer_size for streamed data
This should increase the effectiveness of ffio_ensure_seekback by reducing the
number of buffer reallocations and memmoves/memcpys because even a small
seekback window requires max_buffer_size+window_size buffer space.
avformat/aviobuf: discard part of the IO buffer in ffio_ensure_seekback if needed
Previously ffio_ensure_seekback never flushed the buffer, so successive
ffio_ensure_seekback calls were all respected. This could eventually cause
unlimited memory and CPU usage if a demuxer called ffio_ensure_seekback on all
it's read data.
Most demuxers however only rely on being able to seek back till the position of
the last ffio_ensure_seekback call, therefore we change the semantics of
ffio_ensure_seekback so that a new call can invalidate seek guarantees of the
old. In order to support some level of "nested" ffio_ensure_seekback calls, we
document that the function only invalidates the old window (and potentially
discards the already read data from the IO buffer), if the newly requested
window does not fit into the old one.
This way we limit the memory usage for ffio_ensure_seekback calls requesting
consecutive data windows.
avformat/mpjpegdec: make sure we seek back to the ensured buffer
It was possible for the old code to seek back before the most recently read
data if start of a new multipart was across read boundaries. Now we read some
small sections multiple times to avoid this, but that is OK.
avformat/aviobuf: fix checks in ffio_ensure_seekback
The new buf_size was detemined too conservatively, maybe because of the
off-by-one issue which was fixed recently in fill_buffer. We can safely
substract 1 more from the new buffer size, because max_buffer_size space must
only be guaranteed when we are reading the last byte of the requested window.
Comparing the new buf_size against filled did not make a lot of sense, what
makes sense is that we want to reallocate the buffer if the new buf_size is
bigger than the old, therefore the change in the check.
avfilter/vf_minterpolate: Remove redundant code for freeing
ad73b32d2922f4237405043d19763229aee0e59e added some code for freeing in
the input's config_props function, yet this is unnecessary as uninit is
called anyway if config_props fails.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avfilter/vf_minterpolate: Fix left shift of negative value
This has happened when initializing the motion estimation context if
width or height of the video was smaller than the block size used
for motion estimation and if the motion interpolation mode indicates
not to use motion estimation.
The solution is of course to only initialize the motion estimation
context if the interpolation mode uses motion estimation.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avfilter/vf_minterpolate: Reject too small dimensions
The latter code relies upon the dimensions to be not too small;
otherwise one will call av_clip() with min > max lateron which aborts
in case ASSERT_LEVEL is >= 2 or one will get a nonsense result that may
lead to a heap-buffer-overflow/underflow. The latter has happened in
ticket #8248 which this commit fixes.
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>
Reviewed-by: Paul B Mahol <onemda@gmail.com> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/mjpegdec: Use correct number of codes when init default VLCs
Commit bbc0d0c1fe2b7ecdc4367295594f084f85ad22f5 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 1249698e1b424cff8e77e6a83cfdbc9d11e01aa7 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>
avcodec/mjpegdec: Use correct number of codes for VLC tables
Commit 1249698e1b424cff8e77e6a83cfdbc9d11e01aa7 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.
avformat/dashdec: Reset pointer to NULL after freeing it
This is currently safe here, because the effective lifetime of
adaptionset_lang is parse_manifest_adaptationset() (i.e. the pointer
gets overwritten each time on entry to the function and gets freed
before exiting the function), but it is nevertheless safer to reset the
pointer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
libavformat/dashdec: Fix issue with dash on Windows
Use xmlFree instead of av_freep
snip from libxml2:
* xmlGetProp:
...
* Returns the attribute value or NULL if not found.
* It's up to the caller to free the memory with xmlFree().
According to libxml2, you are supposed to use xmlFree instead of free
on the pointer returned by it, and also using av_freep on Windows will
call _aligned_free instead of normal free, causing _aligned_free to raise
SIGTRAP and crashing ffmpeg and ffplay.
Signed-off-by: Christopher Degawa <ccom@randomderp.com>
Paul B Mahol [Fri, 2 Oct 2020 10:16:49 +0000 (12:16 +0200)]
avcodec/tiff: do not abort decoding if strips are available
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.
Mark Reid [Sat, 3 Oct 2020 23:31:58 +0000 (16:31 -0700)]
libswcale/input: use more accurate planer rgb16 yuv conversions
These conversion appears to be exhibiting the same rounding error as the rgbf32 formats where.
I seperated the rounding value from the 16 and 128 offsets, I think it makes it a little more clear.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
James Almer [Tue, 6 Oct 2020 14:20:24 +0000 (11:20 -0300)]
avcodec/av1dec: avoid probing with av1dec
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.