This codec supports FLAG_B_PICTURE_REFERENCES. We need to correctly fill
the reference_pic_flag with is_reference variable instead of 0 for B
frames.
Signed-off-by: Tong Wu <tong1.wu@intel.com>
libva2 doesn't require a fixed surface-array any more, so we may use
dynamic frame pool for decoding when libva2 is available, which allows a
downstream element stores more frames from VAAPI decoders and fixes the
error below:
$ ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi \
-i input.mp4 -c:v hevc_vaapi -f null -
...
[h264 @ 0x557a075a1400] get_buffer() failed
[h264 @ 0x557a075a1400] thread_get_buffer() failed
[h264 @ 0x557a075a1400] decode_slice_header error
[h264 @ 0x557a075a1400] no frame!
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
This diff removes 4 unused ARMv7 NEON fixed-point DSP functions.
The function were originally moved here by 4958f35a2 (Dec 2013).
After 9e05421db (Jan 2021), as part of the refactor of the AC3
DSP to consistently use 32-bit sample format in the encoder, these
functions were removed from the DSP function table, but the ARMv7
implementations were kept.
Signed-off-by: Geoff Hill <geoff@geoffhill.org>
When starting on a SEI recovery point close enough to the end of
the stream that draining starts before the recovery point's frame
is output, there can be non-recovered frames in the delayed picture
buffer that would currently cause the decoder to fail to output a
frame. This commit skips such frames and outputs the first recovered
frame, if there exists one.
Signed-off-by: arch1t3cht <arch1t3cht@gmail.com>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
When decoding starts at a SEI recovery point very shortly before the
end of the video stream, there can be frames which are decoded before
the recovery point's frame is output and which will only be output once
the draining has started. Previously, these frames would never be set
as recovered. This commit copies the logic from h264_select_output_frame
to send_next_delayed_frame to properly mark such frames as recovered.
Fixes ticket #10936.
Signed-off-by: arch1t3cht <arch1t3cht@gmail.com>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@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 first release of the CTS for AV1 decoding had incorrect
offsets for the OrderHints values.
The CTS will be fixed, and eventually, the drivers will be
updated to the proper spec-conforming behaviour, but we still
need to add a workaround as this will take months.
Only NVIDIA use these values at all, so limit the workaround
to only NVIDIA. Also, other vendors don't tend to provide accurate
CTS information.
This is needed by Vulkan. Constructing this can't be delegated to CBS
because packets might contain multiple frames (when non-shown frames are
present) but we need separate snapshots immediately before each frame
for the decoder.
When Split frame encoding is enabled, each input frame is partitioned into
horizontal strips which are encoded independently and simultaneously by
separate NVENCs, usually resulting in increased encoding speed compared to
single NVENC encoding.
Signed-off-by: Diego Felix de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
As we can read in ST 2086:
Values outside the specified ranges of luminance and chromaticity values
are not reserved by SMPTE, and can be used for purposes outside the
scope of this standard.
This is further acknowledged by ITU-T H.264 and ITU-T H.265. Which says
that values out of range are unknown or unspecified or specified by
other means not specified in this Specification.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Niklas Haas <git@haasn.dev>
These memcpy operands only depend upon sizeof(SampleType)
(and this size is actually the same for both the fixed-point
and the floating-point encoders for most (all supported?)
systems).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These allocations only depend upon sizeof(SampleType)
(and this size is actually the same for both the fixed-point
and the floating-point encoders for most (all supported?)
systems).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for sharing even more stuff
common to the fixed and floating-point encoders.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Implicitly disabled by 4679a474f0.
Given that no one has ever complained about this, this commit
removes the now dead code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
encode_preinit_audio() already checks that the sample rate
is among AVCodec.supported_samplerates.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is unnecessary (the channel layout guessing code became
moot when the channel layouts were enforced generically)
and also dangerous, as a custom channel layout mapping
would leak in case one was used.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is perfectly legal for users to use a custom layout
that is equivalent to a supported native one.
In this case the union in AVChannelLayout is not an uint64_t mask,
but a pointer to a custom map.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Per the lavu/tx docs:
> * For forward transforms (R2C), stride must be the spacing between two
> * samples in bytes. For inverse transforms, the stride must be set
> * to the spacing between two complex values in bytes.
The code did the reverse.
The stride parameter is currently not respected for RDFT transforms,
but has to be correct, for a potential future change.
Removes the special -I flag specified in the avcodec/bsf/ subdirectory.
This makes code copy-pastable to other parts of the ffmpeg codebase, as
well as simplifying the build script.
It also reduces ambiguity, since there are many instances of same-named
header files existing in both libavformat/ and libavcodec/
subdirectories.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: James Almer <jamrial@gmail.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>
Invalid input files may contain film grain metadata which survives
ff_h274_film_grain_params_supported() but does not pass
av_film_grain_params_select(), leading to a SIGSEGV on hevc_frame_end().
Fix this by duplicating the av_film_grain_params_select() check at frame
init time.
An alternative solution here would be to defer the incompatibility check
to hevc_frame_end(), but this has the downside of allocating a film
grain buffer even when we already know we can't apply film grain.
Fixes: https://trac.ffmpeg.org/ticket/10951
