Giving elements of a structure called StyleBox names like
"style_start" or "style_end" is redundant, especially given
that the relevant variables are also called style.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_image_copy() expects an array of four pointers according to its
declaration; although it currently only touches pointers that
are actually in use (depending upon the pixel format) this might
change at any time (as has already happened for the linesizes
in d7bc52bf45).
This fixes a -Wstringop-overflow= warning with GCC 11.2.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_image_copy() expects an array of four pointers and linesizes
according to its declaration; it currently only pointers that are
actually in use (depending upon the pixel format), but this might
change at any time. It has already happened for the linesizes in
d7bc52bf45 and so increasing their
array fixes a stack-buffer overread.
This fixes a -Wstringop-overflow= and -Wstringop-overread warning
from GCC 11.2.
Reviewed-by: Linjie Fu <linjie.justin.fu@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Old system is:
OSX version: 10.11.6
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Up until now, the h264_redundant_pps_bsf stored the initial value
of pic_init_qp_minus26 of the most recently encountered PPS;
it also modified the slices based upon to assumption that
the most recent PPS is the PPS the slice belongs to.
Yet this assumption is flawed, as there can be several PPS
with different IDs that are visible at any given time.
If these have different pic_init_qp_minus26 values,
the output can be invalid.
Fix this by directly using the pic_init_qp_minus26 value of
the input PPS.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
extradata_pic_init_qp is unset since
fa75e43875
(and resetting current_pic_init_qp to the value it had in extradata
never made much sense).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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>
Andreas Rheinhardt
Lynne
Michael Niedermayer
Limin Wang
Hao Chen
Shiyou Yin
James Almer
rcombs
Alex Xu (Hello71)
Matt Oliver