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
avcodec/mv30: Fix several integer overflows in idct_1d()
Fixes: signed integer overflow: -1846510390 + -361755993 cannot be represented in type 'int' Fixes: 23941/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MV30_fuzzer-5654696631730176 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/pgxdec: Fix invalid shift in write_frame_*
Fixes: left shift of negative value -121 Fixes: 23911/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGX_fuzzer-4986800258154496 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avformat/iff: Check data_size not overflowing int64
Fixes: Infinite loop Fixes: 25844/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5660803318153216 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Reviewed-by: Peter Ross <pross@xvid.org> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Anton Khirnov [Fri, 5 Jun 2020 09:17:49 +0000 (11:17 +0200)]
lavu/buffer: add a convenience function for replacing buffers
A common pattern e.g. in libavcodec is replacing/updating buffer
references: unref old one, ref new one. This function allows simplifying
such code and avoiding unnecessary refs+unrefs if the references are
already equivalent.
avformat/argo_brp: allow v1.1 ASF streams to have a non-22050 sample rate in certain circumstances
It seems that in files where the BASF block isn't first, v1.1 ASF streams are
allowed to be non-22050. Either this format is really inconsistent, or
FX Fighter and Croc just ignored the sample rate field, requiring the v1.1
restriction in the first place.
This bumps the version to 1.2 in these streams so they're not "corrected".
Found in Alien Odyssey games files in:
./GRAPHICS/COMMBUNK/{{COMADD1,COMM2_{1,2,3E},COMM3_{2,3,4,5,6}},FADE{1,2}}.BRP
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
This proved beneficial for performance: For the sample [1] the number
of decicycles in one decode call decreased from 155851561 to 108158037
for Clang 10 and from 168270467 to 128847479 for GCC 9.3. For x86-32
compiled with GCC 9.3 and run on an x64 Haswell the number increased
from 158405517 to 202215769, so that the cached bitstream reader is only
enabled if HAVE_FAST_64BIT is set. These values are the average of 10
runs each looping five times over the input.
The fraps decoder already checked for overreads manually (and errored
out in this scenario), yet it still enabled implicit checks, leading to
worse performance and more code size.
This commit disables the implicit bitstream reader checks. For the
sample [1] this improves performance from 195105896 to 155851561
decicycles for Clang 10 and from 222801887 to 168270467 decicycles when
compiled with GCC 9.3. These values are the average of 10 runs each
looping ten times over the input.
avcodec/utvideodec: Avoid qsort when creating Huffman tables
The Ut video format uses Huffman trees which are only implicitly coded
in the bitstream: Only the lengths of the codes are coded, the rest has
to be inferred by the decoder according to the rule that the longer
codes are to the left of shorter codes in the tree and on each level the
symbols are descending from left to right.
Because longer codes are to the left of shorter codes, one needs to know
how many non-leaf nodes there are on each level in order to know the
code of the next left-most leaf (which belongs to the highest symbol on
that level). The current code does this by sorting the entries to be
ascending according to length and (for entries with the same length)
ascending according to their symbols. This array is then traversed in
reverse order, so that the lowest level is dealt with first, so that the
number of non-leaf nodes of the next higher level is known when
processing said level.
But this can also be calculated without sorting: Simply count how many
leaf nodes there are on each level. Then one can calculate the number of
non-leaf nodes on each level iteratively from the lowest level upwards:
It is just half the number of nodes of the level below.
This improves performance: For the sample from ticket #4044 the amount
of decicycles for one call to build_huff() decreased from 1055489 to
446310 for Clang 10 and from 1080306 to 535155 for GCC 9.
Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/utvideodec/enc: Fix edge case of creating Huffman table
The Ut Video format stores Huffman tables in its bitstream by coding
the length of a given symbol; it does not code the actual code directly,
instead this is to be inferred by the rule that a symbol is to the left
of every shorter symbol in the Huffman tree and that for symbols of the
same length the symbol is descending from left to right. With one
exception, this is also what our de- and encoder did.
The exception only matters when there are codes of length 32, because
in this case the first symbol of this length did not get the code 0,
but 1; this is tantamount to pretending that there is a (nonexistent)
leaf of length 32. This is simply false. The reference software agrees
with this [1].
Now that the HuffEntries are no longer sorted by the MagicYUV decoder,
their symbols are trivial: The symbol of the element with index i is i.
They can therefore be removed. Furthermore, despite the length of the
codes being in the range 1..32 bits, the actual value of the codes is
<= 4096 (for 12 bit content). The reason for this is that the longer
codes are on the left side of the tree, so that the higher bits of
these codes are simply zero. By using an uint16_t for the codes and
removing the symbols entry, the size of each HuffEntry is decreased from
eight to four, saving 16KB of stack space.
Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/magicyuv: Avoid AV_QSORT when creating Huffman table
The MagicYUV format stores Huffman tables in its bitstream by coding
the length of a given symbol; it does not code the actual code directly,
instead this is to be inferred by the rule that a symbol is to the left
of every shorter symbol in the Huffman tree and that for symbols of the
same length the symbol is ascending from left to right.
Our decoder implemented this by first sorting the array containing
length and symbol of each element according to descending length and
for equal length, according to ascending symbol. Afterwards, the current
state in the tree got encoded in a variable code; if the next array entry
had length len, then the len most significant bits of code contained
the code of this entry. Whenever an entry of the array of length
len was processed, code was incremented by 1U << (32 - len). So two
entries of length len have the same effect as incrementing code by
1U << (32 - (len - 1)), which corresponds to the parent node of length
len - 1 of the two nodes of length len etc.
This commit modifies this to avoid sorting the entries before
calculating the codes. This is done by calculating how many non-leaf
nodes there are on each level of the tree before calculating the codes.
Afterwards every leaf node on this level gets assigned the number of
nodes already on this level as code. This of course works only because
the entries are already sorted by their symbol initially, so that this
algorithm indeed gives ascending symbols from left to right on every
level.
This offers both speed- as well as (obvious) codesize advantages. With
Clang 10 the number of decicycles for build_huffman decreased from 1561987 to 1228405; for GCC 9 it went from 1825096 decicyles to 1429921.
These tests were carried out with a sample with 150 frames that was
looped 13 times; and this was iterated 10 times. The earlier reference
point here is from the point when the loop generating the codes was
traversed in reverse order (as the patch reversing the order led to
performance penalties).
Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/magicyuv: Fix edge case of building Huffman table
The MagicYUV format stores Huffman tables in its bitstream by coding
the length of a given symbol; it does not code the actual code directly,
instead this is to be inferred by the rule that a symbol is to the left
of every shorter symbol in the Huffman tree and that for symbols of the
same length the symbol is ascending from left to right. With one
exception, this is also what our decoder did.
The exception only matters when there are codes of length 32, because
in this case the first symbol of this length did not get the code 0,
but 1; e.g. if there were exactly two nodes of length 32, then they
would get assigned the codes 1 and 2 and a node of length 31 will get
the 31-bit code 1 which is a prefix of the 32 bit code 2, making the
Huffman table invalid. On the other hand, if there were only one symbol
with the length 32, the earlier code would accept this un-Huffman-tree.
Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/magicyuv: Don't invert order unnecessarily
The MagicYUV decoder currently sets both the length and the symbol field
of an array of HuffEntries; hereby the symbol of the ith entry (0-based)
is just i. Then said array gets sorted so that entries with greater
length are at the end and entries with the same length are ordered so
that those with smaller symbols are at the end. Afterwards the newly
sorted array is traversed in reverse order. This commit instead inverts
the ordering and traverses the array in its ordinary order in order to
simplify understanding.
Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
projects / ffmpeg / log