The format of a mov_text (3GPP Timed Text) sample is:
uint16_t text_length;
uint8_t text[text_length];
TextSampleModifierBox text_modifier;
Yet in case our encoder receives an AVSubtitle with multiple
ASS AVSubtitleRects, it creates something like this:
uint16_t text_length;
uint8_t text[text_length_1];
TextSampleModifierBox text_modifier_1;
uint8_t text[text_length_2];
TextSampleModifierBox text_modifier_2;
...
where text_length is the sum of all the text_length_*.
This commit fixes this by writing the TextSampleModifierBoxes only
after all the rects have been written.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids abusing a variable called length for the return value
and ensures that the AVBPrint is always reset before using it;
previously this has been forgotten in some error paths.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Regression since af043b839c.
Fixes ticket #9409.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: out of array read
Fixes: 40284/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP3_fuzzer-4599568176644096
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>
Fixes: Timeout
Fixes: 41083/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GEM_fuzzer-5843826518917120
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>
Freeing the new H.264 specific fields has been forgotten.
(This leak only appears in case the encoder has not been completely
drained.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, it has only been freed when the QSVFrame is reused,
so that the last one contained in it leaked at the end.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since commit 3bbe0c210b, the Payloads
array of every QSVFrame leaks as soon as the frame is reused;
the leak is small and not very noticeable, but if there is an attempt
to use said array the ensuing crash is much more noticeable.
This happens when encoding H.264 with A53 CC side data.
Furthermore, if said array can not be allocated at all, an AVFrame
leaks.
Fix all of this by not allocating the array separately at all; put it
in QSVFrame instead and restore the Payloads array upon reusing the
frame.
Finally, use av_freep() instead of av_free() to free the payload
entries.
Reviewed-by: Xiang, Haihao <haihao.xiang@intel.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: out of array access
Fixes: Timeout
Fixes: 40481/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VQA_fuzzer-6502647583080448
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In order to know that the earlier code did not use uninitialized
values one needs to know that the lowest four bits of each used
value of pframe_block4x4_coefficients_tab do not vanish identically.
E.g. Coverity did not get this and warned about it in ticket #1466632.
Fix this by slightly rewriting the code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The check for m->size >= 0xF000 is intended to avoid skipping too much
garbage data between JPEG frames in test_roman (thus missing next SOI),
but it erroneously also skips valid markers between SOI and SOS. Instead
of this, we should simply skip parsing markers other than SOI after EOI.
That way, we will not accidentally skip over SOI due to some garbage
between frames. There is still a small risk of encountering FFD8 in the
garbage data, but the chance of this is fairly low.
Fixes: https://trac.ffmpeg.org/ticket/8967
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
h263_get_motion_length() forgot to take an absolute value;
as a consequence, a negative index was used to access an array.
This leads to potential crashes, but mostly it just accesses what
is to the left of ff_mvtab (unless one uses ASAN), thereby defeating
the purpose of the AV_CODEC_FLAG2_NO_OUTPUT because the sizes of
the returned packets differ from the sizes the encoder would actually
have produced.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For dst->have_sse will be assigned by ctx->have_sse soon(code line 23).
Reviewed-by: James Zern <jzern-at-google.com@ffmpeg.org>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
C99/C11 6.3.2.3 5: "Any pointer type may be converted to an integer
type. [...] If the result cannot be represented in the integer type,
the behavior is undefined." So stop casting pointers to int; use
uintptr_t instead.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This context is transient, so putting it on the stack is more natural.
Also reduces codesize: 24E6->2296 B with GCC 10 and -O3.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add Branch Target Identifiers (BTIs) to all functions defined in
AArch64 assembly files. Most of the BTI landing pads are added
automatically by the 'function' macro.
BTI support is turned on or off at compile time based on the presence
of the __ARM_FEATURE_BTI_DEFAULT feature macro.
A binary compiled with BTI support can be executed on an Armv8-A
processor without BTI support because the instructions are defined in
NOP space.
Signed-off-by: Jonathan Wright <jonathan.wright@arm.com>
Signed-off-by: Elijah Ahmad <elijah.ahmad@arm.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Change AArch64 assembly code to use:
ret x<n>
instead of:
br x<n>
"ret x<n>" is already used in a lot of places so this patch makes it
consistent across the code base. This does not change behavior or
performance.
In addition, this change reduces the number of landing pads needed in
a subsequent patch to support the Armv8.5-A Branch Target
Identification (BTI) security feature.
Signed-off-by: Jonathan Wright <jonathan.wright@arm.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
There is no reason to wrap them in #ifndef guards, they should only be
defined here and nowhere else. The define guards just add the
possibility to accidentally use the same FF_API name in different
libraries.
Fixes: signed integer overflow: 2105344 * 539033345 cannot be represented in type 'int'
Fixes: out of array write
Fixes: 39956/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SPEEX_fuzzer-4766419250708480
Fixes: 40293/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SPEEX_fuzzer-5219910217760768
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
x264.h: "the payloads of all output NALs are guaranteed to be
sequential in memory." Therefore we can omit the loop.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
