This switches the jpegxl_collect_codestream_header function to use
avcodec/bytestream2, which better enforces barriers, and should avoid
overrunning buffers with jxlp boxes if the size is zero or if the size
is so small the box is invalid.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Fixes: 58528/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5834725318328320
Fixes: index 16 out of bounds for type 'int [16]'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: pointer index expression with base 0x000000000000 overflowed to 0xfffffffffffffff8
Fixes: 58440/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5956015530311680
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: avcodec/takdsp.c:44:23: runtime error: signed integer overflow: -2097158 - 2147012608 cannot be represented in type 'int'
Fixes: 58417/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TAK_fuzzer-5268919664640000
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This makes the null pointer checks match mpv_motion_internal()
Fixes: NULL pointer dereference
Fixes: 59671/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG1VIDEO_fuzzer-4993004566609920
Fixes: 59678/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEGVIDEO_fuzzer-4893168991338496
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 read
Fixes: 59673/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG1VIDEO_fuzzer-5194311374077952
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -38912000 + -2109276160 cannot be represented in type 'int'
Fixes: 59670/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RKA_fuzzer-4987563245699072
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: left shift of 34136248 by 6 places cannot be represented in type 'int'
Fixes: 58429/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RKA_fuzzer-5692211592560640
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The implementation is flawed in that the frame opaque data is not in
fact correctly reordered along with the packets, but is being output in
packet input order, just like the dts are.
This reverts commit 3553809703.
I've been sitting on this for 3 1/2 years now(!), and I finally got
around to fixing the loose ends and convincing myself that it was
correct. It follows the same basic structure as yadif_cuda, including
leaving out the edge handling, to avoid expensive branching.
As we are introducing two new formats and supporting conversions
between them, and also with the existing 0rgb32/0bgr32 formats, we get
a combinatorial explosion of kernels. I introduced a few new macros to
keep the things mostly managable.
The conversions are all simple, following existing patterns, with four
specific exceptions. When converting from 0rgb32/0bgr32 to rgb32/bgr32,
we need to ensure the alpha value is set to 1. In all other cases, it
can just be passed through, either to be used or ignored.
When an option could not be found, print its name and value. Note that
this is not done while applying the options in
avfilter_graph_segment_apply_opts() to give the caller the option of
handling the missing options in some other way.
The issue is that with a threadsafe hwaccel and multiple enabled
frame threads, hwaccel->uninit() is never called.
Previously, the function was guaranteed to never have any threads
with hwaccel contexts, so it never bothered to uninit any.
nvenc declares support for these formats, but if hwcontext_cuda doesn't
do that as well, then it's not possible to hwupload them for use in a
possible cuda pipeline before encoding.
I'm not sure why I originally did this, but there's no good reason to
put pointers to the cuda context and stream in the priv struct. They
are directly available in the device context that is already being
stored there.
