The user has no business modifying the underlying AVCodec.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If a sequence header has already been found, it is certain that next
startcode (being disjoint from the sequence header startcode) can begin
at index four at the earliest.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: Regression since 1f20969457
Found-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Test case fate-checkasm-h264pred failed in latest community code.
This patch fixed the bug.
Signed-off-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -1429092 * -32596 cannot be represented in type 'int'
Fixes: 24419/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAVESYNTH_fuzzer-5157849974702080
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Although the ICC specifications say to check for this, libtiff doesn't
and neither does any other TIFF implementation, and the TIFF specs
say that Photoshop has a different way to encapsulate ICC profiles,
and are asking for advice on how to deal with it.
So basically, photoshop puts a different type than what's specified,
no other implementation checks for this, we do because we tried to
follow the specs although its harmless to not, and ran into this bug
because we didn't know about it.
Fixes: signed integer overflow: 998938090 + 1169275991 cannot be represented in type 'int'
Fixes: 23411/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP9_fuzzer-4644692330545152
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If encoding fails, the AVPacket that ought to contain the encoded packet
is already unreferenced generically.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The array in question can not be too large (only 26 elements), so it can
simply be put on the context.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Saves allocations, checks for the allocations as well as frees.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The init function first allocates an AVFrame and then some buffers; if
one of the buffers couldn't be allocated, the AVFrame leaks. Solve this
by setting the FF_CODEC_CAP_INIT_CLEANUP flag.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
They are not explicitly in the bitstream in this case, but it is helpful
to be able to use these values without always needing to check the flag
beforehand.
Since c6a63e1109, the parameter sets
modified as content of PPS units were references shared with the
CodedBitstreamH264Context, so modifying them alters the parsing process
of future access units which meant that frames often got discarded
because invalid values were parsed. This patch makes h264_redundant_pps
compatible with the reality of reference-counted parameter sets.
Fixes#7807.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
Use the unit type table to determine what we need to do to clone the
internals of the unit content when making copies for refcounting or
writeability. (This will still fail for units with complex content
if they do not have a defined clone function.)
Setup and naming from a patch by Andreas Rheinhardt
<andreas.rheinhardt@gmail.com>, but with the implementation changed
to use the unit type information if possible rather than requiring a
codec-specific function.
Unit types are split into three categories, depending on how their
content is managed:
* POD structure - these require no special treatment.
* Structure containing references to refcounted buffers - these can use
a common free function when the offsets of all the internal references
are known.
* More complex structures - these still require ad-hoc treatment.
For each codec we can then maintain a table of descriptors for each set of
equivalent unit types, defining the mechanism needed to allocate/free that
unit content. This is not required to be used immediately - a new alloc
function supports this, but does not replace the old one which works without
referring to these tables.
Fixes memleaks with some encoders that don't unref the packet before
returning.
This is consistent with the behavior of AVCodec.encode()
implementations in encode_simple_internal().
Found-by: mkver
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: James Almer <jamrial@gmail.com>
Andreas Rheinhardt
Michael Niedermayer
gxw
Harry Mallon
Gyan Doshi
Lynne
Paul B Mahol
Limin Wang
Fei Wang
Mark Thompson
James Almer