Context:
1. In the case sps_subpic_info_present=0, there is a single subpicture
which includes the entire picture.
2. When sps_subpic_info_present=0, we might be using Reference Picture
Resampling (RPR), in which picture sizes might differ in the PPS,
rather than in the SPS.
Because of 2., we can't rely on the sequence-level variables
sps_subpic_width_minus1 and sps_subpic_height_minus1 to derive the
picture-level variable num_entry_points, as the picture might have a
different size to the picture used when deriving those sequence-level
variables.
Prior to the fix, in the case of a tile containing multiple slices
(pps_num_exp_slices_in_tile != 0) the number of slices was temporarily
allowed to exceed pps_num_slices_in_pic_minus1+1 and therefore
VVC_MAX_SLICES. The number of slices was later verified, but while the
current slice index was higher than expected it was used to write to a
array of size VVC_MAX_SLICES, leading to an OOB write.
To rectify this, the patch adds some checks at an earlier stage, to
ensure that the slice index i + j at no point exceeds
pps_num_slices_in_pic_minus1.
Fixes #YWH-PGM40646-30
The semantics of sh_num_ref_idx_active_minus1[ i ] state that
When the current slice is a P slice, the value of NumRefIdxActive[ 0 ] shall be greater than 0.
When the current slice is a B slice, both NumRefIdxActive[ 0 ] and NumRefIdxActive[ 1 ] shall be greater than 0.
Fixes: use of uninitialized memory
Fixes: 449549597/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-5600497089445888
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reported-by: Michael Niedermayer michael@niedermayer.cc
seq_decode is used to ensure that a picture and all of its reference
pictures use the same SPS. Any time the SPS changes, seq_decode should
be incremented. Prior to this patch, seq_decode was incremented in
frame_context_setup, which is called after the SPS is potentially
changed in decode_sps. Should the decoder encounter an error between
changing the SPS and incrementing seq_decode, the SPS could be modified
while seq_decode was not incremented, which could lead to invalid
reference pictures and various downstream issues. By instead updating
seq_decode within the picture set manager, we ensure seq_decode and the
SPS are always updated in tandem.
Previously, we set s->slice_initialized to 0 to prevent other slice
segments from depending on this slice segment only if hls_slice_header
failed. If decode_slice fails for some other reason, however, before
decode_slice_data is called to bring the context back into a consistent
state, then slices could depend on this slice segment while it is in an
invalid state. This can cause segmentation faults and other sorts of
nastiness. Patch fixes this by always setting s->slice_initialized to 0
while the state is inconsistent.
Resolves#11652.
This loosens the coupling between CBS and the decoder by no longer using
CodedBitstreamH266Context (containing the most recently parsed PSs & PH)
to retrieve the PSs & PH in the decoder. Doing so is beneficial in two
ways:
1. It improves robustness to the case in which an AVPacket doesn't
contain precisely one PU.
2. It allows the decoder parameter set manager to properly handle the
case in which a single PU (erroneously) contains conflicting
parameter sets.
Signed-off-by: Frank Plowman <post@frankplowman.com>
av_exif_* functions are part of libavcodec's public API since
ad77345a5d, so the EXIF objects can't
be disabled.
Fixes compilation with --disable-everything.
Consider the following sequence of NALUs (with some PPSs etc. omitted
for brevity):
1. SPS (ID=0, content=A)
2. IDR (SPS=0)
3. IDR (SPS=0)
4. SPS (ID=0, content=B)
5. TRAIL (SPS=0)
When decode_sps is called for NALU 3., ps->sps_id_used is cleared as
IDRs are one way of forming a CLVSS. Then, old_sps is non-NULL
containing the result of calling decode_sps for NALU 2. We haven't
received any SPSs between NALUs 2. and 3., therefore old_sps and rsps
are identical and the function returns. The issue is that, at this
point, ps->sps_id_used is still zero despite the SPS being used for IDR
3. This results in the check for conflicting SPSs not working properly
when decode_sps is called for NALU 5., allowing prediction between
pictures with different SPSs and probably all sorts of other
shenanigans.
Patch addresses the problem outlined above by also setting
ps->sps_id_used in the early return case.
Prior to this patch, kth_order_egk_decode could read arbitrarily
large values which then overflowed and caused various issues.
Patch fixes this by making kth_order_egk_decode falliable,
requiring the caller to specify an upper bound and returning an
error if the read value would exceed that bound.
This patch resolves the same issue as
eb52251c0a, but I think this is the proper
fix as it also addresses issues with syntax elements besides
ff_vvc_num_signalled_palette_entries.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Add handling here for
sps_scaling_matrix_for_alternative_colour_space_disabled_flag.
Also add parentheses to make behaviour a little more explicit,
where &&'s precedence over || was relied on previously.
Reported-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Frank Plowman <post@frankplowman.com>
Add three missing requirements on bitstream conformance from 7.4.3.19 of
H.266 (V3). Issue found using fuzzing.
Signed-off-by: Frank Plowman <post@frankplowman.com>
When called for palette-predicted CUs, boundary_strength could cause
undefined behaviour due to accessing uninitialised motion information.
The spec doesn't include this, but in the reference software it seems
the deblock strength is always set to 0 for palette CUs due to some
implementation details: perhaps this is a spec issue?
Signed-off-by: Frank Plowman <post@frankplowman.com>
In d5dbcc00d8, it was hoped that detection
of subpicture overlaps could be performed at the tile level, so as to
avoid introducing per-CTU checks. Unfortunately since that patch,
fuzzing has indicated there are some structures involving
pps_subpic_one_or_more_tiles_slice where tile-level checking is not
sufficient. Performing the check at the CTU level should (touch wood)
be the be-all and and-all of this, as CTUs are the lowest common
denominator of the picture partitioning.
Signed-off-by: Frank Plowman <post@frankplowman.com>
A sample with a particular partitioning structure that could not be read
correctly before 26c5d8cf5d
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
If pps_single_slice_per_subpic_flag is 1,
slice_{width,height}_in_tiles are undefined and we must instead get the
dimensions of the slice by referring to the corresponding subpicture.
Signed-off-by: Frank Plowman <post@frankplowman.com>
When pps_num_exp_slices_in_tile[i] is nonzero, the ith tile is made up
of pps_num_exp_slices_in_tile[i] slices stacked atop one another, where
the height of the jth slice in the ith tile is given by
pps_exp_slice_height_in_ctus_minus1[i][j]. The sum of the heights of
the slices in the tile should not exceed the height of the tile itself.
Signed-off-by: Frank Plowman <post@frankplowman.com>
This is essentially a re-implementation of
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20241005223955.54158-1-post@frankplowman.com/
That patch was not applied last time. Instead we opted to identify
issues which could be caused by invalid subpicture layouts and remedy
those issues where they manifest, either through error detection or code
hardening. This was primarily implemented in the set
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=13381.
This has worked to some degree, however issues with subpicture layouts
continue to crop up from the fuzzer and I've fixed a number of bugs
related to subpicture layouts since then. I think it's best to return
to the initial plan and simply check if the subpicture layout is valid
initially.
This implementation is also lighter than the first time -- by doing a
bit more logic in pps_subpic_less_than_one_tile_slice, we are able to
store a tile_in_subpic map rather than a ctu_in_subpic map. This
reduces the size of the map to the point it becomes possible to allocate
it on the stack. Similar to 8bd66a8c95,
the layout is also validated in the slice map construction code, rather
than in the CBS, which avoids duplicating some logic.
Signed-off-by: Frank Plowman <post@frankplowman.com>
In the case pps_subpic_less_than_one_tile_slice is called, the
subpicture is smaller than the tile and so there are multiple
subpictures in the tile. Of course, then, not all the
subpictures can start in the top-left corner as the code before the
patch does. Patch fixes this, so each subpicture starts at the
signalled location as is specified in section 6.5.1 of H.266(V3).
Signed-off-by: Frank Plowman <post@frankplowman.com>
The clamping of idxYInv from H.266(V3) section 8.8.2.3 was missing.
This could lead to OOB reads from lmcs->pivot or input_pivot.
I also changed the derivation of the forward LMCS idx to use a shift
rather than a division for speed and as this is actually how the
variable is declared in the specification (8.7.5.2).
Signed-off-by: Frank Plowman <post@frankplowman.com>
In the fail: block of decode_nal_units, a check as to whether fc->ref is
nonzero is used. Before this patch, fc->ref was set to NULL in
frame_context_setup. The issue is that, by the time frame_context_setup
is called, falliable functions (namely slices_realloc and
ff_vvc_decode_frame_ps) have already been called. Therefore, there
could arise a situation in which the fc->ref test of decode_nal_units'
fail: block is performed while fc->ref has an invalid value. This seems
to be particularly prevalent in situations where the FrameContexts are
being reused. The patch resolves the issue by moving the assignment of
fc->ref to NULL to the very top of decode_nal_units, before any falliable
functions are called.
Signed-off-by: Frank Plowman <post@frankplowman.com>
The criteria for slice structure validity is similar to that of
subpicture structure validity that we saw not too long ago [1].
The relationship between tiles and slices must satisfy the following
properties:
* Exhaustivity. All tiles in a picture must belong to a slice. The
tiles cover the picture, so this implies the slices must cover the
picture.
* Mutual exclusivity. No tile may belong to more than one slice, i.e.
slices may not overlap.
In most cases these properties are guaranteed by the syntax. There is
one noticable exception however: when pps_tile_idx_delta_present_flag is
equal to one, each slice is associated with a syntax element
pps_tile_idx_delta_val[i] which "specifies the difference between the
tile index of the tile containing the first CTU in the ( i + 1 )-th
rectangular slice and the tile index of the tile containing the first
CTU in the i-th rectangular slice" [2]. When these syntax elements are
present, the i-th slice can begin anywhere and the usual guarantees
provided by the syntax are lost.
The patch detects slice structures which violate either of the two
properties above, and are therefore invalid, while building the
slice map. Should the slice map be determined to be invalid, an
AVERROR_INVALIDDATA is returned. This prevents issues including
segmentation faults when trying to decode, invalid bitstreams.
[1]: https://ffmpeg.org//pipermail/ffmpeg-devel/2024-October/334470.html
[2]: H.266 (V3) Section 7.4.3.5, Picture parameter set RBSP semantics
Signed-off-by: Frank Plowman <post@frankplowman.com>
This sample is rather difficult, containing a lot of subtle edge cases
which revealed errors in the VVC decoder. It covers 88.4% of lines in
libavcodec/vvc and brings the line coverage of the entire VVC fate suite
from 96.3% to 97.2%.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
When the current subpicture has sps_subpic_treated_as_pic_flag equal to
1, motion vectors are cropped such that they cannot point to other
subpictures. This was accounted for in the prediction logic, but not
in pred_get_y, which is used by the scheduling logic to determine which
parts of the reference pictures must have been reconstructed before
inter prediction of a subsequent frame may begin. Consequently, where a
motion vector pointed to a location significantly above the current
subpicture, there was the possibility of a race condition. Patch fixes
this by cropping the motion vector to the current subpicture in
pred_get_y.
Signed-off-by: Frank Plowman <post@frankplowman.com>
In 7.4.3.20 of H.266 (V3), there are two similarly-named variables:
scalingMatrixDcPred and ScalingMatrixDcRec. The old code set
ScalingMatrixDcRec, rather than scalingMatrixDcPred, in the first two
branches of the conditions on scaling_list_copy_mode_flag[id] and
aps->scaling_list_pred_mode_flag[id]. This could lead to decode
mismatches in sequences with explicitly-signalled scaling lists.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Reduces memory consumption by ~4MB for 1080p video with a maximum delay
of 16 frames by packing various information related to MIP:
* intra_mip_flag, 1 bit
* intra_mip_transposed_flag, 1 bit
* intra_mip_mode, 4 bits
Into a single byte.
Co-authored-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: Frank Plowman <post@frankplowman.com>
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>
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>
This reverts commit 110d8549d5.
I have been working through fixing bugs, particularly crashes I've
found using a fuzzer, in the VVC decoder for the past few months.
While I won't claim it is now bug-free, it is considerably more
resilient than it was and I think in a position to have the
experimental flag removed for release 7.1.
Additionally, most of the Main 10 features of VVC which were missing
version of the decoder released in 7.0 have now been implemented.
This includes the most major missing features: IBC, subpictures and RPR.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Implement the missing requirements from H.266 (V3) p. 106 on the
position and size of subpictures whose dimensions are provided
explicitly.
Signed-off-by: Frank Plowman <post@frankplowman.com>
The previous logic relied on the subpicture boundaries coinciding with
the tile boundaries. Per 6.3.1 of H.266 (V3), vertical subpicture
boundaries are always tile boundaries however the same cannot be said
for horizontal subpicture boundaries. Furthermore, it is possible to
construct an illegal bitstream where vertical subpicture boundaries are
not coincident with tile boundaries. In these cases, the condition of
the while loop would never be satisfied resulting in an OOB read on
col_bd/row_bd.
Patch fixes this issue by replacing != with <, thereby not requiring
subpicture boundaries and tile boundaries to be coincident.
Signed-off-by: Frank Plowman <post@frankplowman.com>
ff_vvc_frame_rpl uses the flags to detect whether a frame is in use.
Therefore, in the case of a CVSS AU (RASL/GDR with
NoOutputBeforeRecoveryFlag) with ph_non_ref_pic_flag = 1, the frame
would be freed before it is used. Fix this by always marking the
current frame with VVC_FRAME_FLAG_SHORT_REF, as is done by the HEVC
decoder.
Signed-off-by: Frank Plowman <post@frankplowman.com>
From H.266 (V3) (09/2023) p. 321:
It is a requirement of bitstream conformance that the luma block
vector bvL shall obey the following constraints:
- CtbSizeY is greater than or equal to
((yCb + (bvL[ 1 ] >> 4)) & (CtbSizeY − 1)) + cbHeight
This patch checks this is true, which fixes crashes on fuzzed
bitstreams.
Signed-off-by: Frank Plowman <post@frankplowman.com>
When the SPS associated with a particular SPS ID changes, invalidate all
the PPSs which use that SPS ID. Fixes crashes with illegal bitstreams.
This is done in the CBS, rather than in libavcodec/vvc/ps.c like the SPS
ID reuse validation, as parts of the CBS parsing process for PPSs
depend on the SPS being referred to.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Before After
-------------------------------------------------
make fate-vvc CPU Time (No ASM) 131.52s 134.83s
libavcodec/vvc/* Line Coverage 95.3% 96.9%
inter_template.c Line Coverage 74.3% 88.2%
inter.c Line Coverage 85.3% 99.2%
Signed-off-by: Frank Plowman <post@frankplowman.com>
On the top of p. 112 in VVC (09/2023):
It is a requirement of bitstream conformance that the values of
qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
of −QpBdOffset to 63, inclusive for i in the range of 0 to
numQpTables − 1, inclusive, and j in the range of 0 to
sps_num_points_in_qp_table_minus1[ i ] + 1, inclusive.
Additionally, don't discard the return code from sps_chroma_qp_table.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Allocations in the following lines depend on the pixel shift, and so
these buffers must be reallocated if the pixel shift changes. Patch
fixes segmentation faults in fuzzed bitstreams.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Per VVCv3 p. 157, the collocated reference picture used in temporal
motion vector prediction must have RprConstraintsActiveFlag equal to
zero and the same CTU size as the current picture. Add these checks,
fixing crashes decoding some fuzzed bitstreams.
Additionally, only set up the collocated reference picture if it is
actually going to be used (i.e. if ph_temporal_mvp_enabled_flag is 1),
else legal RPR bitstreams will fail the new checks.
Co-authored-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: Frank Plowman <post@frankplowman.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>
num_units_in_tick and time_scale are both 32-bit unsigned integers.
Storing them as ints was causing overflows.
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>
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.
Previously, the following syntax elements were not read in the case
sps_num_subpics_minus is 0:
* sps_subpic_id_len_minus1
* sps_subpic_id_mapping_explicitly_signalled_flag
* sps_subpic_id_mapping_present_flag
* sps_subpic_id[i]
This was causing failures to decode bitstreams, for example the DVB's
"VVC HDR UHDTV1 OpenGOP 3840x2160 50fps HLG10 PiP" V&V bitstream.
Patch fixes this by moving the reads for these syntax elements out a
scope.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The spec says "the value of sps_num_subpics_minus1 shall be in the
range of 0 to MaxSlicesPerAu − 1, inclusive."
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The PPS should be used instead of the SPS to get the current picture's
dimensions. Using the SPS can cause issues if the resolution changes
mid-sequence. In particular, it was leading to invalid memory accesses
if the resolution decreased.
Patch replaces sps->{width,height} with pps->{width,height}. It also
removes sps->{width,height}, as these are no longer used anywhere.
Fixes crash when decoding DVB V&V test sequence
VVC_HDR_UHDTV1_ClosedGOP_Max3840x2160_50fps_HLG10_res_change_without_RPR
Signed-off-by: Frank Plowman <post@frankplowman.com>
If the number of CTUs reduces between one picture and the next, the
slice_idx table is reduced in size in the frame_context_for_each_tl call
on vvcdec.c:321. When initialising the slice_idx table on vvcdec.c:325,
the old code uses fc->tab.sz.ctu_count when calculating the table size.
fc->tab.sz.ctu_count holds the old ctu count at this point however, not
being updated to hold the new ctu count until vvcdec.c:342. This causes
an out-of-bounds write.
Patch fixes the problem by using pps->ctb_count, which was just used
when allocating the table, in place of fc->tab.sz.ctu_count when
initialising the table.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Check that vps_each_layer_is_an_ols_flag, which indicates that "at
least one OLS specified by the VPS contains more than one layer," is
set if num_multi_layer_olss is non-zero.
Fixes: 65160/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_METADATA_fuzzer-4665241535119360
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
nal->skipped_bytes_pos contains the positions of errors relative to the
start of the slice header, whereas the position they were tested against
is relative to the start of the slice data, i.e. one byte after the end
of the slice header.
Patch fixes this by storing the size of the slice header in H266RawSlice
and adding it to the position given by the GetBitContext before
comparing to skipped_bytes_pos. This fixes AVERROR_INVALIDDATAs for
various valid bitstreams, such as the LMCS_B_Dolby_2 conformance
bitstream.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Resolves the following undefined behavior sanitiser error:
runtime error: shift exponent 32 is too large for 32-bit type 'int'
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
VVC specifies << as arithmetic left shift, i.e. x << y is equivalent to
x * pow2(y). C's << on the other hand has UB if x is negative. This
patch removes all UB resulting from this, mostly by replacing x << y
with x * (1 << y), but there are also a couple places where the OOP was
changed instead.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The gcrypt definition of `bn_new` used to use the return statement
on errors, with an AVERROR return value, regardless of the signature
of the function where the macro is used - it is called in
`dh_generate_key` and `ff_dh_init` which return pointers. As a result,
compiling with gcrypt and the ffrtmpcrypt protocol resulted in an
int-conversion warning. GCC 14 may upgrade these to errors [1].
This patch fixes the problem by changing the macro to remove `AVERROR`
and instead set `bn` to null if the allocation fails. This is the
behaviour of all the other `bn_new` implementations and so the result is
already checked at all the callsites. AFAICT, this should be the only
change needed to get ffmpeg off Fedora's naughty list of projects with
warnings which may be upgraded to errors in GCC 14 [2].
[1]: https://gcc.gnu.org/pipermail/gcc/2023-May/241264.html
[2]: https://www.mail-archive.com/devel@lists.fedoraproject.org/msg196024.html
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Reduce false positives for VVC files by adding additional checks in
`vvc_probe`. Specifically, `nuh_temporal_id_plus1` is tested for valid
values in extra cases depending on the NAL unit type, as per ITU-T H.266
section 7.4.2.2.
Resolves trac #10703.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Texinfo 7.0 produces quite different HTML to Texinfo 6.8. Without
this change, enumerated option flags (i.e. Possible values of x
are...) render as white text on a white background with Texinfo 7.0
and are unreadable. This change removes a style for the selector
`.table .table` which causes the background to turn white for these
elements. As far as I can tell, it is not actually used anywhere in
files generated by Texinfo 6.8.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Resolves trac ticket #10636 (http://trac.ffmpeg.org/ticket/10636).
Texinfo 7.0, released in November 2022, changed the names of various
functions. Compiling docs with Texinfo 7.0 resulted in warnings and
improperly formatted documentation. More old names appear to have
been removed in Texinfo 7.1, released October 2023, which causes docs
compilation to fail.
This commit addresses the issue by adding logic to switch between the old
and new function names depending on the Texinfo version. Texinfo 6.8
produces identical documentation before and after the patch.
CC
https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1938238.htmlhttps://bugs.gentoo.org/916104
Signed-off-by: Frank Plowman <post@frankplowman.com>
example clips:
* 12b444vvc1_E_Sony_2
* 12b444Ietsrc_A_Kwai_2
* 10b444P16_D_Sony_2
* 12b444Iepp_A_Sharp_2
* 12b444SPetsrc_B_Kwai_2
Co-authored-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Frank Plowman
