Keeping only the latest packet fed to the decoder works only for decoders that
return a frame immediately after every consumed packet. Decoders that consume
several packets before they return a frame will fill said frame with properties
taken from the last consumed packet instead of the earliest.
Signed-off-by: James Almer <jamrial@gmail.com>
And replace the flags parameter with a function callback that can be used to
copy the contents of the packet (e.g, av_packet_ref and av_packet_copy_props).
Signed-off-by: James Almer <jamrial@gmail.com>
The CineForm HD encoder attempts to allocate several buffers in its init
function; yet if only some of these allocations succeed, the
successfully allocated buffers leak. This is fixed 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>
Fill the array with the software pix_fmt and move the avctx->hwaccel
check back to the proper place.
Also remove the avoid probing flag to ensure an external av1 decoder
will not set a pix_fmt we don't want during format probing.
Signed-off-by: James Almer <jamrial@gmail.com>
Let the internal decoder take care of it, as frame reordering
may result in different values exported by either module.
Signed-off-by: James Almer <jamrial@gmail.com>
This AV1 decoder is currently only used for hardware accelerated decoding.
It can be extended into a native decoder in the future, so set its name to
"av1" and temporarily give it the lowest priority in the codec list.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: -2.4187e+09 is outside the range of representable values of type 'int'
Fixes: signed integer overflow: -14512205 + -2147483648 cannot be represented in type 'int'
Fixes: 20492/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPC7_fuzzer-5747263166480384
Fixes: 23528/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPC7_fuzzer-5747263166480384
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: index -1 out of bounds for type 'const uint8_t [6][16]'
Fixes: out of array read
Fixes: shift exponent -21 is negative
Fixes: 25422/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-5748258226569216
Fixes: shift exponent 8039082 is too large for 32-bit type 'int'
Fixes: 25430/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-5698567770210304
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>
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>
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>
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>
Andreas Rheinhardt