args->bytes here already includes prefix_bytes (see
SSIZE_ROUND macro), so including it here again and
forgetting it when offsetting skip seems wrong.
This only works because prefix_bytes is currently
always zero in this encoder.
(This has been added in b88be742fa
without any reason.)
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_get_encode_buffer() already emits an error message of its own.
While just at it, also check for ret < 0 instead of just ret != 0.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This works out a bit more favourably than VP8's due to:
- additional multiplications that can be vectored,
- hardware-supported fixed-point rounding mode.
vp7_luma_dc_wht_c: 3.2
vp7_luma_dc_wht_rvv_i64: 2.0
According to the VVC specification (section 8.5.1), the maximum width/height of a subblock passed for DMVR SAD is 16. This along with previous constraint requiring width * height >= 128 means that 8x16, 16x8, and 16x16 are the only allowed sizes. This re-labels vvc_sad_16_128 to vvc_sad_16 to reflect this and adds a comment about the block size constraints. There's no functionality change.
If there are missing references, h264 decode does error concealment
by copying previous refs which means there will be duplicated surfaces.
Check long_ref and frame_idx in addition to surface when looking for
the other field to avoid trying to merge with wrong picture.
Also allow to merge with multiple pictures in case there are duplicates
of the other field.
Signed-off-by: David Rosca <nowrep@gmail.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
When there are multiple tiles in one slice buffer, use multiple slice
params to avoid sending the same slice buffer multiple times and thus
increasing the bitstream size the driver will need to upload to hw.
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Signed-off-by: David Rosca <nowrep@gmail.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
MFX_FRAMETYPE_IDR is ORed to the frame type for AVC and HEVC keyframes,
and MFX_FRAMETYPE_I is taken as keyframe flag for other codecs when
getting the output surface from the SDK, hence we may mark the output
frame as keyframe accordingly.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
This saves one instruction and frees up A5, which will be repurposed in
later changes. Unfortunately, we need to add quite a lot of alternative
code for this.
The H.265 specification is quite clear on this case:
> When min_display_mastering_luminance is not in the range of 1 to
> 50000, the nominal maximum display luminance of the mastering display
> is unknown or unspecified or specified by other means not specified in
> this Specification.
And so the current code is correct in marking luminance data as invalid
if min luminance is set to 0. However, this breaks playback of at least
several real-world Blu-ray releases, for example La La Land, Planet of
the Apes, and quite possibly a lot more. These come with ostensibly
valid max_luminance tags (1000 nits), but min_luminance set to 0.
Loosen up this requirement by guarding it behind FF_COMPLIANCE_STRICT.
We still reject blatantly invalid metadata (wrong value range on
luminance, max set to 0, max below min, min above 50 nits etc.), so this
shouldn't cause any unintended regressions.
Fixes: https://github.com/mpv-player/mpv/issues/14177
Fixes: CID1435166 Unused value
Fixes: CID1529221 Unused value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: The warnings from CID1598553 Uninitialized scalar variable
Passing partly initialized structs is ugly and asking for hard to rieproduce bugs,
The uninitialized fields where not used
Reviewed-by: "Xiang, Haihao" <haihao.xiang-at-intel.com@ffmpeg.org>
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Helps: CID1518967 Unchecked return value
Helps: CID1518968 Unchecked return value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The Constant Quality (CQ) range for the AV1 codec is actually 0 to
63, contrary to what is stated in the header and documentation.
Signed-off-by: Diego Felix de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
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>
Fields under the segmentation switch are never reset on a new frame, and
retain the value from the previous frame. This bugs out a bunch of
hwaccel drivers when segmentation is disabled but update_map isn't
reset because they don't ignore values behind switches. This commit also
resets the temporal field, though it may not be required.
We also do this for vp8 [1] so this commit is just mirroring the vp8
logic.
This fixes an issue with certain samples [2] that causes blocky
artifacts with vaapi, d3d11va and cuda (and possibly others).
Mesa worked around [3] this by ignoring these fields if
segmentation.enabled is 0, but d3d11va still displays blocky artifacts.
[1] 2e877090f9:/libavcodec/vp8.c#l797
[2] https://github.com/mpv-player/mpv/issues/13533
[3] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27816
Signed-off-by: llyyr <llyyr.public@gmail.com>
Fix output mismatch when decode clip with crop(conf_win_*offset in
syntax) info by using system memory:
$ ffmpeg -c:v hevc_qsv -i conf_win_offet.bit -y out.yuv
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
The SDK may provide HDR metadata for HDR streams via mfxExtBuffer
attached on output mfxFrameSurface1
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
128-bit is the maximum, not the minimum here. Larger vector sizes can
result in reads past the end of the noise value table.
This partially reverts commit cdcb4b98b7.
Since the SBR noise application optimisations are currently restricted
to hardware with 128-bit vectors, and use a quadruple multipler, they
can load up to 16 32-bit elements. But the "loads" are of 2 segments,
or 16 pairs of single precision float.
Thus we need to expand the dupiclated section of the noise table from
2x8 to 2x16 to avoid overflows.
This loop correctly assumes that VLMAX=16 (4x128-bit vectors
with 32-bit elements) and 32 >= pred_order > 16. We need to alternate
between VL=16 and VL=t2=pred_order-16 elements to add up to pred_order.
The current code requests AVL=a2=pred_order elements. In QEMU and on
thte K230 hardware, this sets VL=16 as we need. But the specification
merely guarantees that we get: ceil(AVL / 2) <= VL <= VLMAX. For
instance, if pred_order equals 27, we could end up with VL=14 or VL=15
instead of VL=16. So instead, request literally VLMAX=16.
Andreas Rheinhardt
Wu Jianhua
Pierre-Anthony Lemieux
sunyuechi
Rémi Denis-Courmont
Stone Chen
David Rosca
Haihao Xiang
Niklas Haas
Michael Niedermayer
Diego Felix de Souza
Frank Plowman
llyyr
Fei Wang