The current code tries the access the codecpar of a nonexistent
audio stream when seeking. Stop that. Fixes ticket #9121.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_cpu_count() intends to emit a debug message containing the number of
logical cores when called the first time. The check currently works with
a static volatile int; yet this does not help at all in case of
concurrent accesses by multiple threads. So replace this with an
atomic_int.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
A buffer may leak in case of YUVA444P10 with dimensions that are not
both divisible by 16.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When allocating a BSF fails, it could happen that the BSF's close
function has been called despite a failure to allocate the private data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes a crash with ISOBMFF extradata containing no OBUs.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is a regression since switching to the generic CBS BSF code.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also don't unnecessarily copy the input data around if it needn't be
reversed; and remove a redundant memset -- av_fast_padded_malloc()
already does this for us.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The DSS demuxer currently decrements a counter that should be positive
at the beginning of read_packet; should it become negative, it means
that the data to be read can't be read contiguosly, but has to be read
in two parts. In this case the counter is incremented again after the
first read if said read succeeded; if not, the counter stays negative.
This can lead to problems in further read_packet calls; in tickets #9020
and #9023 it led to segfaults if one tries to seek lateron if the seek
failed and generic seek tried to read from the beginning. But it could
also happen when av_new_packet() failed and the user attempted to read
again afterwards.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When encoding E-AC-3, whether coupling is on or not determines whether
an additional frame based coupling exponent strategy element frmcplexpstr
(of size five bits) is present in the bitstream. So just add five to the
number of bits when counting them instead of adding 5*s->cpl_on (the
latter field is currently only 0 or 1, so it doesn't make a difference).
Furthermore, move some parts of the bit allocation that doesn't change
per-frame to count_frame_bits_fixed() (which is only run once during
init).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AC-3 and EAC-3 are codecs whose packet sizes are known in advance,
so one can use the min_size parameter of ff_alloc_packet2() to
allocate exactly this amount. This avoids a memcpy later in
av_packet_make_refcounted() in encode_simple_internal().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since the very beginning (since de6d9b6404)
the AC-3 encoder used AC3_MAX_CODED_FRAME_SIZE (namely 3840) for the
size of the output buffer (without any check at all).
This causes problems when encoding EAC-3 for which the maximum is too small,
smaller than the actual size of the buffer: One can run into asserts used
by the PutBits API. Ticket #8513 is about such a case and this commit
fixes it by using the real size of the buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Temporary fix until AVClass::child_class_next is gone.
Reviewed-By: James Almer <jamrial@gmail.com>
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
All instances of adding attached pictures to a stream or adding
a stream and an attached packet to said stream have several things
in common like setting the index and flags of the packet, setting
the stream disposition etc. This commit therefore factors this out.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Before commit f1e17eb446, the qtrle
encoder had undefined pointer arithmetic: Outside of a loop, two
pointers were set to point to the ith element (with index i-1) of
a line of a frame. At the end of each loop iteration, these pointers
were decremented, so that they pointed to the -1th element of the line
after the loop. Furthermore, one of these pointers can be NULL (in which
case all pointer arithmetic is automatically undefined behaviour).
Commit f1e17eb44 added a check in order to ensure that the elements
never point to the -1th element of the array: The pointers are only
decremented if they are bigger than the frame's base pointer
(i.e. AVFrame.data[0]). Yet this check does not work at all in case of
negative linesizes; furthermore in case the pointer that can be NULL is
NULL initializing it still involves undefined pointer arithmetic.
This commit fixes both of these issues: First, non-NULL pointers are
initialized to point to the element after the ith element and
decrementing is moved to the beginning of the loop. Second, if a pointer
is NULL, it is just made to point to the other pointer, as this allows
to avoid checks before decrementing it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If keeping a reference to an earlier frame failed, the next frame must
be an I frame for lack of reference frame. This commit implements this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Affected ProRes without alpha; affected 32 FATE tests, e.g. prores-422,
prores-422_proxy, prores-422_lt or matroska-prores-header-insertion-bz2.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: out of array access
Fixes: 32264/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LSCR_fuzzer-6684504010915840
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array write
Fixes: 32116/clusterfuzz-testcase-minimized-ffmpeg_dem_SIMBIOSIS_IMX_fuzzer-6702533894602752
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
