(the exact issue is unreproducable but the use of uninitialized data is reproducable)
Should fix: signed integer overflow: -2147483648 - 127 cannot be represented in type 'int'
Should fix: 69881/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-4751301204836352
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
An alternative would be to leave the context unchanged on failure of hls_slice_header()
Fixes: out of array access
Fixes: NULL pointer dereference
Fixes: 69584/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5931086299856896
Fixes: 69724/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5104066422702080
Fixes: 70422/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5908731129298944
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reuses the DC bypass functions from the multiple IDCT functions, to
leverage vector code.
As an added bonus, the caller functions can now rely on the callee functions
to preserve their parameters, thus cutting down on stack spills.
No functional changes. This just moves the assembler so that it can be
referenced by other functions in h264idct_rvv.S with local jumps.
Edited-by: Rémi Denis-Courmont <remi@remlab.net>
The spec allows at least thirty-two zero bits followed by a one to mean
2^32-1, with no constraint on the number of zeroes. The libaom
reference decoder does not match this, instead reading thirty-two zeroes
but not the following one to mean 2^32-1. These two interpretations are
incompatible and other implementations may follow one or the other.
Therefore reject thirty-two zeroes because the intended behaviour is not
clear.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If the sBIT chunk size is invalid, we should print a more informative
error message rather than return an error and print nothing.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Indexed color images use three colors for sBIT, but the function
ff_png_get_nb_channels returns 1 in this case. We should avoid erroring
out on valid files in this scenario.
Regression since 84b454935f.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reported-by: Ramiro Polla <ramiro.polla@gmail.com>
Reviewed-by: Marton Balint <cus@passwd.hu>
Fixes: signed integer overflow: 20 * 2314885530818453759 cannot be represented in type 'long'
Fixes: 69098/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG2VIDEO_fuzzer-6107989688778752
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 255 by 24 places cannot be represented in type 'int'
Fixes: 69083/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_UTVIDEO_fuzzer-5608202363273216
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This moves computations out of a loop
This may help with UB in vsynth*-jpeg2000-yuva444p16
Fixes: signed integer overflow: 31665934879948800 * 9998 cannot be represented in type 'long'
Fixes: 69024/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5949662967169024
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 5.92611e+20 is outside the range of representable values of type 'unsigned long'
Fixes: 68984/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5155755073273856
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 1431634944 by 2 places cannot be represented in type 'int'
Fixes: left shift of 1073741824 by 1 places cannot be represented in type 'int'
Fixes: 69061/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC2_fuzzer-6325700826038272
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For a frame comes from AV_HWDEVICE_TYPE_VIDEOTOOLBOX, it's
CVPixelBufferRef is maintained by a pool. CVPixelBufferRef returned
to the pool when frame buffer reference reached to zero. However,
VTCompressionSessionEncodeFrame also hold a reference to the
CVPixelBufferRef. So a new frame get from av_hwframe_get_buffer
may access a CVPixelBufferRef which still used by the encoder.
It's only after vtenc_output_callback that we can make sure
CVPixelBufferRef has been released by the encoder.
The issue can be tested with sample from trac #10884.
ffmpeg -hwaccel videotoolbox \
-hwaccel_output_format videotoolbox_vld \
-i input.mp4 \
-c:v hevc_videotoolbox \
-profile:v main \
-b:v 3M \
-vf scale_vt=w=iw/2:h=ih/2:color_matrix=bt709:color_primaries=bt709:color_transfer=bt709 \
-c:a copy \
-tag:v hvc1 \
output.mp4
Withtout the patch, there are some out of order images in output.mp4.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
ExtraSEI is used as the sourceFrameRefcon of VTCompressionSessionEncodeFrame.
It cannot hold other information which is necessary to fix another issue
in the following patch.
This patch also fixed leak of ExtraSEI on the error path of
vtenc_output_callback.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The VPS referenced by the SPS must always be present as the max value for
sps_max_sub_layers_minus1 is vps_max_sub_layers_minus1. This replaces a buggy
custom range check for the aforementioned field.
Also, add the missing conformance check for sps_temporal_id_nesting_flag while
at it.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: out of array access
Fixes: 69098/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG2VIDEO_fuzzer-6107989688778752
Fixes: 69599/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-4848626296225792.fuzz
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This simplification assumes that the code is correct
Fixes: CID1560036 Logically dead code
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Unlike the 8-bit version, we need two iterations to process this within
128-bit vectors. This adds some extra complexity for pointer arithmetic
and counting down which is unnecessary in the 8-bit variant.
Accordingly the gain relative to C are just slight better than half as
good with 128-bit vectors as with 256-bit ones.
T-Head C908 (2 iterations):
h264_idct8_add_9bpp_c: 17.5
h264_idct8_add_9bpp_rvv_i32: 10.0
h264_idct8_add_10bpp_c: 17.5
h264_idct8_add_10bpp_rvv_i32: 9.7
h264_idct8_add_12bpp_c: 17.7
h264_idct8_add_12bpp_rvv_i32: 9.7
h264_idct8_add_14bpp_c: 17.7
h264_idct8_add_14bpp_rvv_i32: 9.7
SpacemiT X60 (single iteration):
h264_idct8_add_9bpp_c: 15.2
h264_idct8_add_9bpp_rvv_i32: 5.0
h264_idct8_add_10bpp_c: 15.2
h264_idct8_add_10bpp_rvv_i32: 5.0
h264_idct8_add_12bpp_c: 14.7
h264_idct8_add_12bpp_rvv_i32: 5.0
h264_idct8_add_14bpp_c: 14.7
h264_idct8_add_14bpp_rvv_i32: 4.7
Fixes: signed integer overflow: 865309950 * 256 cannot be represented in type 'int'
Fixes: 69191/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6310214413385728
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
