Use dpb_max_num_reorder_pics to control output instead of
dpb_max_dec_pic_buffering, when dpb_max_dec_pic_buffering
is much larger than dpb_max_num_reorder_pics, it may cause
dpb overflow error.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Signed-off-by: elinyhuang <elinyhuang@tencent.com>
The native VVC decoder does not yet support quality/spatial/multiview
scalability. Bitstreams requiring this feature could cause crashes.
Patch fixes this by skipping NAL units which are not in the base layer,
warning the user while doing so.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
sps_log2_ctu_size_minus5 is between 0 and 2, with 3 reserved for future
use. The VVC decoder allows sps_log2_ctu_size_minus5 to be 3, and so
ctb_size_y should be at least 16 bits to prevent overflows. An
alternative patch would leave sps_log2_ctu_size_minus5 as 8 bits and
disallow sps_log2_ctu_size_minus5 = 3.
Signed-off-by: Frank Plowman <post@frankplowman.com>
The 2 which has been changed to an 8 in the array length expression is
the maximum value of sps_bitdepth_minus8. This was missed when updating
to VVCv2, which increased this maximum from 2 to 8.
Signed-off-by: Frank Plowman <post@frankplowman.com>
The size variable here is taken as gospel for the bounds of the input
buffer in later logic. Clamp it to ensure that the returned region
does not extend past that allocated in the underlying GetBitContext,
even in the case entry point offsets are signalled in the bitstream.
Also assert this for good measure.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Key line from the spec is:
"All SPS NAL units with a particular value of sps_seq_parameter_set_id
in a CVS shall have the same content."
Prior to this patch, the VVC decoder's behaviour on encountering a
duplicated SPS ID (within the entire bitstream, not restricted to
a CVS) was simply to replace the entry in the SPS lookup table with the
new data. Illegal bitstreams with multiple SPSs in the same CVS sharing
an ID but differing elsewhere could cause all manner of issues.
The patch tracks which SPS IDs have been used in the given CVS using the
new sps_id_used field of VVCParamSets. If it encounters an SPS with an
ID already in use and whose content differs from the previous SPS, it
throws an AVERROR_INVALIDDATA.
Signed-off-by: Frank Plowman <post@frankplowman.com>
A namespace is unnecessary here given that all these files
are already in the vvc subfolder.
Reviewed-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Such frames will crash when pthread functions are called on the NULL pointer
Fixes: member access within null pointer of type 'VVCFrameThread' (aka 'struct VVCFrameThread')
Fixes: 65160/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_METADATA_fuzzer-4665241535119360 (partly)
Fixes: 65636/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-5394745824182272
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
There are lots of files that don't need it: The number of object
files that actually need it went down from 2011 to 884 here.
Keep it for external users in order to not cause breakages.
Also improve the other headers a bit while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The second part of this condition is intended to check whether the
current quantisation group is in the first CTU column of the current
tile. The issue is that ctb_to_col_bd gives the x-ordinate of the first
column of the current tile *in CTUs*, while xQg gives the x-ordinate of
the quantisation group *in samples*. Rectify this by shifting xQg by
ctb_log2_size to get xQg in CTUs before comparing.
Fixes FFVVC issues #201 and #203.
libavcodec/vvc/vvc_inter.c:823:18: runtime error: signed integer overflow: 1426128896 + 1426128896 cannot be represented in type 'int'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior libavcodec/vvc/vvc_inter.c:823:18
Suggested-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The following cases should set bs to 1:
If the prediction modes are not the same.
If both prediction modes are MODE_IBC, but the motion vector delta is larger than 8 of 1/16 pixels.
see 8.8.3.5
How to reproduce it:
vvencapp -i sintel_trailer_2k_1080p24.y4m --preset fast --additional "IBC=1" -o sintel.266
ffmpeg -i sintel.266 -f md5 -
md5 will mismatch
Found-by: 6ws at https://github.com/ffvvc/FFmpeg/issues/187#issuecomment-1962842135
Otherwise vvc_intra.o gets pulled in by the vvc_mc checkasm
test and it in turn pulls vvc_ctu.o and then the rest of vvcdec
and lavc in. Besides being bad size-wise this also has the downside
that it pulls in avpriv_(cga|vga16)_font from libavutil which are
marked as being imported from another library when building
libavcodec as a DLL and this breaks checkasm because it links
both lavc and lavu statically.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For IBC, we'll utilize the check_available function.
However, neither MVP nor merge mode need to check the motion estimation region.
Let's rename it to avoid confusion.
Intra Block Copy relies on reconstructed pixels from the current frame.
We skip IBC during the inter prediction stage and handle it during the reconstruction stage.
An Intra Block Copy clip may use different modes for luma and chroma.
For example, MODE_IBC for luma and MODE_INTRA for chroma.
We have to check luma and chroma CuPredMode (cpm) separately.
Jun Zhao