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.
avformat/movenc: Don't forget to free fragment buffers
The buffers used when fragmented output is enabled have up until now not
been freed in the deinit function; they leak e.g. if one errors out of
mov_write_trailer() before one reaches the point where they are normally
written out and freed. This can e.g. happen if allocating new vos_data
fails at the beginning of mov_write_trailer().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/movenc: Free old vos_data before overwriting it
Otherwise the old data leaks whenever extradata needs to be rewritten
(e.g. when encoding FLAC with our encoder that sends an updated
extradata packet at the end).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/movenc: Fix segfault when remuxing rtp hint stream
When remuxing an rtp hint stream (or any stream with the tag "rtp "),
the mov muxer treats this as one of the rtp hint tracks it creates
internally when ordered to do so; yet this track lacks the
AVFormatContext for the hinting rtp muxer, leading to segfaults in
mov_write_udta_sdp() if a "trak" atom is written for this stream; if not,
the stream's codecpar is freed by mov_free() as if the mov muxer owned
it (it does for the internally created "rtp " tracks), but without
resetting st->codecpar, leading to double-frees lateron. This commit
therefore ignores said tag which makes rtp hint streams unremuxable.
This fixes tickets #8181 and #8186.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: Infinite loop Fixes: 26016/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-6195663833137152 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>
avcodec/dxtory: Fix negative stride shift in dx2_decode_slice_420()
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>
James Almer [Sun, 4 Oct 2020 13:21:59 +0000 (10:21 -0300)]
avcodec/av1dec: partially clean state on frame decoding errors
Fixes: member access within null pointer of type 'TileGroupInfo' (aka 'struct TileGroupInfo') Fixes: 25725/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AV1_fuzzer-5166692706287616 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: James Almer <jamrial@gmail.com>
The manual states "there is virtually no reason to use that encoder.".
It supports less sample formats than the native encoder, is less efficient
than the native encoder and is also slower and pretty much remains untested.
libwavpack also isn't being fuzzed, which given that we plug the parameters
without any sanitizing them looks concerning.
avformat/asfdec_f: Change order or operations slightly
Fixes: signed integer overflow: 20 * 5184056935931942919 cannot be represented in type 'long' Fixes: 25466/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4798660247552000 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avformat/dxa: Use av_rescale() for duration computation
Fixes: signed integer overflow: 8224000000 * 1629552639 cannot be represented in type 'long' Fixes: 24908/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4658478506049536 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/vc1_block: Fix integer overflow in ac value
Fixes: signed integer overflow: 25488 * 87381 cannot be represented in type 'int' Fixes: 24765/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1_fuzzer-5108259565076480 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Martin Storsjö [Wed, 30 Sep 2020 09:27:00 +0000 (12:27 +0300)]
rtsp: Fix infinite loop in listen mode with UDP transport
In listen mode with UDP transport, once the sender has sent
the TEARDOWN and closed the connection, poll will indicate that
one can read from the connection (indicating that the socket has
reached EOF and should be closed by the receiver as well). In this
case, parse_rtsp_message won't try to parse the command (because
it's no longer in state STREAMING), but previously just returned
zero.
Prior to f6161fccf8c5720ceac1ed1df8ba60ff8fed69f5, this caused
udp_read_packet to return zero, which is treated as EOF by
read_packet. But after that commit, udp_read_packet would continue
if parse_rtsp_message didn't return an explicit error code.
To keep the original behaviour from before that commit, more
explicitly return an error in parse_rtsp_message when in the wrong
state.
Fixes: #8840 Signed-off-by: Martin Storsjö <martin@martin.st>
avformat/movenc: Fix stack overflow when remuxing timecode tracks
There are two possible kinds of timecode tracks (with tag "tmcd") in the
mov muxer: Tracks created internally by the muxer and timecode tracks
sent by the user. If any of the latter exists, the former are
deactivated. The former all belong to another track, the source
track; the latter don't have a source track set, but the index of the
source track is initially zeroed by av_mallocz_array(). This is a
problem since 3d894db700cc1e360a7a75ab9ac8bf67ac6670a3: Said commit added
a function that calculates the duration of tracks and the duration of
timecode tracks is calculated by rescaling the duration (calculated by
the very same function) of the source track. This gives an infinite
recursion if the first track (the one that will be treated as source
track for all timecode tracks) is a timecode track itself, leading to a
stack overflow.
This commit fixes this by not using the nonexistent source track
when calculating the duration of timecode tracks not created internally
by the mov muxer.
Reviewed-by: Martin Storsjö <martin@martin.st> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/utils: Don't forget cleaning up when allocating priv_data fails
Allocating an AVCodecContext's priv_data used to be the first object
allocated in avcodec_open2(), so it was unnecessary to goto free_and_end
(which does the cleanup) upon error here. But this is no longer so since f3a29b750a5979ae6847879fba758faf1fae88d0.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/utils: Improve check for freeing codec private options
Don't check for AVCodec.priv_data_size (which is always true if
AVCodec.priv_class is set). Instead check for AVCodecContext.priv_data
to actually exist.
(Note: av_opt_free(NULL) is a no-op.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The first thing avcodec_open2() allocates is the AVCodecInternal. If
allocating it fails, a jump to end occurs; but if an error happens after
its allocation, a jump to free_and_end happens which frees all
allocations performed so far and then jumps to end. Yet free_and_end
contained a check for AVCodecInternal (after having already dereferenced
it to check whether ff_thread_free() needs to be called) which is of
course always true. So remove it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Nicolas George [Mon, 14 Sep 2020 19:23:20 +0000 (21:23 +0200)]
fate: add scale filters for big-endian architectures.
Filters mostly work in native endianness, but they must output
a specified endianness, usually little: that requires a final
conversion for big endian.
I do not know what's the deal with gif-deal: inserting explicitly
the filters that are implicitly inserted result in less frames in
output. Probably a strange problem of duration.
avcodec/utils: Only call codec->close if init has been called
avcodec_open2() also called the AVCodec's close function if an error
happened before init had ever been called if the AVCodec has the
FF_CODEC_CAP_INIT_CLEANUP flag set. This is against the documentation of
said flag: "The codec allows calling the close function for deallocation
even if the init function returned a failure."
E.g. the SVQ3 decoder is not ready to be closed if init has never been
called.
Fixes: NULL dereference Fixes: 25762/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SVQ3_fuzzer-5716279070294016 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Reviewed-by: Paul B Mahol <onemda@gmail.com> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Tian Qi [Fri, 28 Aug 2020 01:13:02 +0000 (09:13 +0800)]
avcodec/videotoolboxenc: move pthread_cond_signal after add buffer to the queue
In the VT encoding insertion by FFmpeg,
and vtenc_q_push is callback to add the encoded data
to the singly linked list group in VTEncContext,
and consumers are notified to fetch it.
However, because it first informs consumers of pthread_cond_signal,
and then inserts the data into the tail,
there is a multi-thread safety hazard.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org> Signed-off-by: Rick Kern <kernrj@gmail.com>
Tian Qi [Thu, 27 Aug 2020 02:53:27 +0000 (10:53 +0800)]
avcodec/videotoolboxenc: don't wait when flushing data
because there is run in thread mode, few times will block
the workflow at the wait, so check the status is flushing data,
don't wait when flushing data.
Signed-off-by: Tian Qi <tianqi@kuaishou.com> Signed-off-by: Steven Liu <lq@chinaffmpeg.org> Signed-off-by: Rick Kern <kernrj@gmail.com>
Zhao Zhili [Wed, 26 Aug 2020 21:38:44 +0000 (05:38 +0800)]
avcodec/videotoolboxenc: fix align issue
bool a53_cc is accessed as int:
src/libavutil/opt.c:129:9: runtime error: store to misaligned
address 0x7fbf454121a3 for type 'int', which requires 4 byte alignment
projects / ffmpeg / log