Vulkan supports some stupidly odd hardware, that unfortunately,
most modern GPUs happen to be.
The DPB images for encoders may be required to be preallocated
all at once, and rather than be individual frames, be layers of
a single frame.
As the hw_base_encode code is written with the thought that either
the driver or the device itself supports sane image allocation,
Vulkan does not leave us with this option.
So, in the case that the hardware does not support individual
frames to be used as DPBs, make the DBP frames context optional,
and let the subsystem manage this.
This commit cleans up and refactors the mess of private state upon
private state that used to be.
Now, FFHWBaseEncodePicture is fully initialized upon call-time,
and, most importantly, this lets APIs which require initialization
data for frames (VkImageViews) to initialize this for both the
input image, and the reconstruction (DPB) image.
Signed-off-by: Tong Wu <wutong1208@outlook.com>
This codec's capabilities should be set dynamically based on the value
of strict_std_compliance, when available. This will allow us to finally
get rid of the strictness hack in ffmpeg_filter.c.
In order to avoid breaking older clients not yet using the new API, we
need to add backwards compatibility for codecs which have switched from
init_static() to get_supported_config().
This function can be removed entirely once the deprecated static fields
are removed.
This replaces the myriad of existing lists in AVCodec by a unified API
call, allowing us to (ultimately) trim down the sizeof(AVCodec) quite
substantially, while also making this more trivially extensible.
In addition to the already covered lists, add two new entries for color
space and color range, mirroring the newly added negotiable fields in
libavfilter.
Once the deprecation period passes for the existing public fields, the
rough plan is to move the commonly used fields (such as
pix_fmt/sample_fmt) into FFCodec, possibly as a union of audio and video
configuration types, and then implement the rarely used fields with
custom callbacks.
I went through all codecs and put them into five basic categories:
1. JPEG range only
2. MPEG range only
3. Explicitly tagged
4. Broken (codec supports both but encoder ignores tags)
5. N/A (headerless or pseudo-formats)
Filters in category 5 remain untouched. The rest gain an explicit
assignment of their supported color ranges, with codecs in category
4 being set to MPEG-only for safety.
It might be considered redundant to distinguish between 0 (category 5)
and MPEG+JPEG (category 3), but in doing so we effectively communicate
that we can guarantee that these tags will be encoded, which is distinct
from the situation where there are some codecs that simply don't have
tagging or implied semantics (e.g. rawvideo).
A full list of codecs follows:
JPEG range only:
- amv
- roqvideo
MPEG range only:
- asv1, asv2
- avui
- cfhd
- cljr
- dnxhd
- dvvideo
- ffv1
- flv
- h261, h263, h263p
- {h263,vp8}_v4l2m2m
- huffyuv, ffvhuff
- jpeg2000
- libopenjpeg
- libtheora
- libwebp, libwebp_anim
- libx262
- libxavs, libxavs2
- libxvid
- mpeg1video, mpeg2video
- mpeg2_qsv
- mpeg2_vaapi
- mpeg4, msmpeg4, msmpeg4v2, wmv1, wmv2
- mpeg4_omx
- prores, prores_aw, prores_ks
- rv10, rv20
- snow
- speedhq
- svq1
- tiff
- utvideo
Explicitly tagged (MPEG/JPEG):
- {av1,h264,hevc}_nvenc
- {av1,h264,hevc}_vaapi
- {av1,h264,hevc,vp8,vp9,mpeg4}_mediacodec
- {av1,h264,hevc,vp9}_qsv
- h264_amf
- {h264,hevc,prores}_videotoolbox
- libaom-av1
- libkvazaar
- libopenh264
- librav1e
- libsvtav1
- libvpx, libvpx-vp9
- libx264
- libx265
- ljpeg
- mjpeg
- vc2
Broken (encoder ignores tags):
- {av1,hevc}_amf
- {h264,hevc,mpeg4}_v4l2m2m
- h264_omx
- libxeve
- magicyuv
- {vp8,vp9,mjpeg}_vaapi
N/A:
- ayuv, yuv4, y41p, v308, v210, v410, v408 (headerless)
- pgmyuv (headerless)
- rawvideo, bitpacked (headerless)
- vnull, wrapped_avframe (pseudocodecs)
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>
Handle them together with other sps-dependent arrays.
Note that current code only allocates these arrays when hwaccel is not
set, but this is wrong as the relevant code runs BEFORE get_format() is
called and hence before we know whether hwaccel is in use.
Active VPS is a property of the decoding process, not of the list of
parameter sets.
Check that the VPS can only change in a base layer - while this can
never happen currently (as no other layers can exist in the decoder), it
will become useful when multilayer decoding is supported.
Start by moving the DPB to it.
Only one context exists for now, so decoder behaviour should not change
with this commit, but that will change in the future.
The code previously returned ENOMEM, despite this not being an
allocation problem, but rather a bitstream problem referring to data not
currently available.
Fixes playback of such streams, as it allows further processing of NAL
units after skipping the broken SEI NAL.
Implemented gpu driver check.
10-bit patch works incorrectly on driver version lower than 23.30.
Signed-off-by: Dmitrii Ovchinnikov <ovchinnikov.dmitrii@gmail.com>
The x86 optimized dct_quantize only calculates the last nonzero
coefficient correctly if the zigzag scan order is used. For the
alternate scan order, this value is incorrect.
To work around this, the dct_unquantize functions process the entire
block if the alternate scan order is used.
But a second workaround (bb198e198a) was added that recalculates the
last nonzero coefficient after dct_quantize is called if the alternate
scan order is used.
This commit removes the first workaround, which became redundant.
It's safe to assume that LOCAL_ALIGNED_16 does indeed align. Otherwise
we would have many more problems...
This assert was added in f8188626 all the way back in 2003.
Fixes:
https://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-tsan&time=20240823175808
Reproduction steps:
./configure --enable-memory-poisoning --toolchain=gcc-tsan --disable-stripping && make fate-vvc
Root cause:
We hold the current frame's lock while updating progress for other frames,
which also requires acquiring other frame locks. This could potentially lead to a deadlock.
However, I don't think this will happen in practice because progress updates are one-way, with no cyclic dependencies.
But we need this patch to make FATE happy.
Implement load/save loop filter and segment parameters defined in
section 7.20 and 7.21 in spec for show_existing_frame frames.
Fixes ticket #11151.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Lynne
James Almer
Niklas Haas
Frank Plowman
Anton Khirnov
Hendrik Leppkes
Araz Iusubov
Evgeny Pavlov
nyanmisaka
Michael Fabian 'Xaymar' Dirks
Fei Wang
Ramiro Polla
Nuo Mi