Fixes: 70991/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WEBP_fuzzer-5544067620995072
Fixes: use of uninintailized value
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Use of uninitialized value
Fixes: 71350/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ILBC_fuzzer-6322020827070464
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The rv60_qp_to_idx table only supports qp up to 31 on intra
Fixes: global-buffer-overflow
Fixes: 377543818/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-5160167345291264
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>
H.266 (V3) section 7.4.12.8: "The value of lMvd[ compIdx ] shall be in
the range of −2^{17} to 2^{17} − 1, inclusive."
Signed-off-by: Frank Plowman <post@frankplowman.com>
Per H.266 (V3) section 7.4.3.19, LmcsMaxBinIdx is set equal to
15 - lmcs_delta_max_bin_idx. The previous code instead had it equal to
15 - lmcs_min_bin_idx. This could cause decoder mismatches.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Previously, the code only stored the MIP mode and transpose flag in the
relevant tables at the top-left corner of the CU. This information ends
up being retrieved in ff_vvc_intra_pred_* not based on the CU position
but instead the transform unit position (specifically, using the x0 and
y0 from get_luma_predict_unit). There might be multiple transform units
in a CU, hence the top-left corner of the transform unit might not
coincide with the top-left corner of the CU. Consequently, we need to
store the MIP information at all positions in the CU, not only its
top-left corner, as we already do for the MIP flag.
Signed-off-by: Frank Plowman <post@frankplowman.com>
The final parameter of check_available determines whether the motion
estimation region constraints imposed in section 8.5.2.3 of H.266 (V3)
on MVP candidates apply to the current candidate or not. In the case of
IBC spatial merge candidates they do not, as their availability is
dependent only on the criteria described in sections 8.6.2.3 and 6.4.4,
which do not include this constraint on the motion estimation region.
Signed-off-by: Frank Plowman <post@frankplowman.com>
MinQtLog2SizeIntraC is usually (eq. (51) from VVCv3) defined as
sps_log2_diff_min_qt_min_cb_intra_slice_chroma + MinCbLog2SizeY
However, in the case ph_log2_diff_min_qt_min_cb_intra_slice_chroma is
present, it is instead (eq. (83) from VVCv3) defined as
ph_log2_diff_min_qt_min_cb_intra_slice_chroma + MinCbLog2SizeY
When ph_log2_diff_max_bt_min_qt_intra_slice_chroma and
ph_log2_diff_max_tt_min_qt_intra_slice_chroma are present, so is
ph_log2_diff_min_qt_min_cb_intra_slice_chroma, and so we should use the
second definition of MinQtLog2SizeIntraC, rather than the first, when
calculating the bounds for these syntax elements.
Signed-off-by: Frank Plowman <post@frankplowman.com>
This does not replicate on my setup, thus this is a blind fix based on ossfuzz trace
Fixes: use of uninitialized value
Fixes: 71747/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5427736120721408
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Use of uninitialized memory
Fixes: 71546/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EATGQ_fuzzer-5607656650244096
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If the function is not inlined, this is more efficient. Also
it allows calling refill() without the check
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Comply with "For purposes other than determining the amount of data in the decoding units
of the bitstream, decoders shall ignore all data that follow the value 63 for nuh_layer_id in a NAL unit"
Rec. ITU-T H.265 v8 (08/2021) Page 67
Fixes: index 63 out of bounds for type 'const int8_t[63]' (aka 'const signed char[63]')
Fixes: clusterfuzz-testcase-fuzzer_loadfile-5109286752026624
Reported-by: Kacper Michajlow <kasper93@gmail.com>
Found-by: ossfuzz
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Remove the MMX versions of these functions and modify the SSE
implementations to avoid using MMX registers.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
The v3 spec reserves CTU size 256. Currently, we use an uint8_t* table to hold cb_width and cb_height.
If a CTU size of 256 is not split, cb_width and cb_height will overflow to 0.
To avoid switching to uint16_t, rejecting CTU size 256 provides a simple solution.
If the current stage reports an error, some variables may not be correctly initialized.
Scheduling the next stage could lead to the use of uninitialized variables.
According to section 6.3.3 "Spatial or component-wise partitionings,"
CTUs should fully cover slices with no overlaps, gaps, or additions.
No overlaps are ensured by task_init_parse.
No gaps and no additions are ensured by this patch.
Co-authored-by: Frank Plowman <post@frankplowman.com>
According to section 6.3.3, 'Spatial or component-wise partitionings,'
Subpictures must cover the entire picture.
Therefore, the total number of subpicture slices should equal the number of picture slices
Co-authored-by: Frank Plowman <post@frankplowman.com>
There are another three cavs_vector variables, ff_cavs_dir_mv,
ff_cavs_intra_mv and un_mv. They don't need align to 8.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
SAN FRME objects specify width/height as well as offsets from top/left.
These offsets need to be taken into account for the diff buffers
as well. Fixes playback of all SAN videos of "Shadows of the Empire",
which have a constant top offset of 60 (640x272 video on a 640x480 window)
and show tons of ghosting and block artifacts.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The codec47 header provides colors to use to clear the
2 difference buffers. This fixes artifacts (black hair, faces) in
Curse of Monkey Island "CURSERNG.SAN" video.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Outlaws' RAE.SAN file did not properly fade out in certain scenes,
but simply turned to black as soon as the first XPAL chunk with
the apply command was encountered.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Some codec47 frames come with an interpolation table:
Combining 2 adjacent pixels into a 16bit value, this value can
then be used as index into the interpolation table to get a new
pixel value. This is used for subcodec 1, which encodes a key-
frame at half width and height, and makes these frame less blocky
appearing.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
When RPU is removed EL should also be removed. This only applies to
HEVC as AV1 based Profile 10 does not support EL at all.
Signed-off-by: Gnattu OC <gnattuoc@me.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
According to the GL_EXT_buffer_reference spec alignment
"must be a power of two and be greater than or equal to the largest scalar/component type in the block."
This means by using u32vec2 we can drop the requirement alignment from 8 bytes to 4 bytes
and save a pack64 call in reverse8 (though I assume in most ISAs that compiles to nothing)
Allows the vc2 vulkan encoder to function without setting PB_UNALIGNED
If caller wrote a divisible by eight number of bits it would write an extra byte.
Also increment by to_write instead of BUF_BYTES which overly pads the bitstream.
The function is quite important to ensure that the output
is always going to be sufficient, and it can change version to
version, so exposing it makes sense.
This allows the encoder to fully saturate all queues the GPU
has, giving a good 10% in certain cases and resolutions.
This also improves error resilience if an allocation fails,
and properly cleans up after itself if it does.
The current parser does things which a parser should not, like skipping parts
of the packet header, but it does not actually able to packetize a raw DNXUC
bitstream.
Rework the parser logic to work similar to other parsers and be able to
correctly packetize raw DNXUC bitstreams.
Bump minor version because the DNXUC codec packet format changes with this.
Normally this would be a breaking change, but in this particular case it should
not cause any issues in practice because the DNXUC codec is relatively new and
we never added a decoder for it.
Signed-off-by: Marton Balint <cus@passwd.hu>