bilateral_cuda, bwdif_cuda and chromakey_cuda call ff_cuda_load_module(),
which lives in cuda/load_helper.c, but their OBJS lines do not pull that
object in; the other CUDA filters that load a module list it. A build
where one of these is the only CUDA filter fails to link, for example:
vf_bwdif_cuda.c:312: undefined reference to `ff_cuda_load_module'
Reproduced for each filter with --disable-everything --enable-avfilter
--enable-filter=<name> --enable-cuda-llvm --enable-ffnvcodec; each links
after this change.
Signed-off-by: lusoris <lusoris@proton.me>
This is a mostly straightforward translation of the logic from ISO 21496.
Implementation notes:
- Slice threading is used to vastly speed up processing
- We quantize the EOTF to a LUT if possible; this doesn't work for HLG becaus
HLG embeds a channel-dependent OOTF. It's possible we could implement a
custom HLG function here in the future, but for now, simply calling out
to the EOTF function is a reasonable fallback.
- Similar to libultrahdr, we use a two-pass approach when the gain range is
unknown a priori, and fold the quantization step into a single pass if
all parameters are specified up-front.
- Unlike libultrahdr, we make an effort to also pick an optimal gamma to
tune the quantized encoding. Users can always disable this by specifying
`:gamma=1.0` explicitly.
- This filter is bidirectional and can also compute an HDR->SDR gainmap,
so the naming is left deliberately abstract internally.
- We need to be careful to avoid platform-specific floating point differences.
This is accomplished by quantizing the floating point values to a fixed
point AVRational representation rather than using av_d2q().
Signed-off-by: Niklas Haas <git@haasn.dev>
This change introduces the basic Vulkan filter machinery, while preserving the
original vf_framerate timing logic. At this stage, the filter simply picks the
temporally closest input frame for the output.
Note that while input frames are not modified in anyway, they must be
deep-copied for output. This ensures that they match the output context, which
may differ from the input context in important way, and avoids extending the
lifetime of hardware decoded frames that are part of the decoder's DPB.
This requires exposing vkCmdCopyImage in the Vulkan function loader, and a
compute queue family and execution pool to record the copy on.
The filter depends on vulkan_1_4 for its Vulkan-Headers requirement; while this
is not required by any of the code in this commit, the final optical-flow
pipeline will need VK_KHR_maintenance9, which first appeared with Vulkan 1.4.
To avoid confusion, the requirement is asserted from the beginning.
This is the minimal level of renames required to get the new filter to function
as a clone of vf_framerate. The context type is inlined from the header, but
there are no actual functional changes.
Convert packed 24/32-bit RGB/BGR/RGBA/BGRA input to PAL8 using a per-frame palette
whose colors are placed on a face-centered cubic lattice (realized as the
scaled D3/D4 checkerboard lattice), with a user-supplied density controlling
the number of lattice steps spanning one color axis.
Only lattice points actually used by a frame enter its palette; if a frame
needs more than 256 of them, the filter will itearatively drop palettte
entries and reassign affected pixels until 256 color remain
lookup uses the Conway-Sloane rounding algorithm. Supported dithering
modes: none, ordered 8x8 bayer (swscale), Cluster & Void blue noise and
Floyd-Steinberg error diffusion.
Co-Authored-by: Fable-5
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This may be faster or slower than the existing specialized kernels,
so I opted not to prefer it by default. I also deliberately didn't expose
additional filter function capabilites yet.
The main motivating reason here is to get correct anti-aliasing behavior
when downscaling, which is currently completely broken.
Signed-off-by: Niklas Haas <git@haasn.dev>
libnpp and the corresponding filters have been deprecated
in commit 994a368451
on 2025-09-26. By the time of our next release,
a year will have passed, so they are removed immediately.
Note: Passing --enable-libnpp to configure results in
a warning about the deprecation and is otherwise a no-op.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This patch adds the transpose_cuda video filter.
It's similar to the existing transpose filter but accelerated by CUDA.
It supports the same pixel formats as the scale_cuda filter.
This also supersedes the deprecated transpose_npp filter.
Example usage:
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i <INPUT> -vf "transpose_cuda=dir=clock" <OUTPUT>
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This just adds a Vulkan compute-based 360-degree video conversion.
It implements a sufficient subset of the most popular 360-degree video formats.
Options such as rotation are dynamic and can be adjusted during runtime.
Some of the work was based on Paul B. Mahol's patch from 2020. There
were spots where the arithmetic conversion was incorrect.
This patch adds screen capture support via AMF vsrc_amf:
ffmpeg -y \
-filter_complex "vsrc_amf=framerate=120:capture_mode=keep_framerate" \
-c:v hevc_amf \
-frames:v 300 \
output_grab.mp4
If the HW frames pool is insufficient,
increase extra_hw_frames in filter_complex.
The supported YUV pixel formats were separated between planar
and semiplanar. This approach reduces the number of CUDA kernels
for all pixel formats.
This patch:
1. Adds support for YUV 4:2:2 planar and semi-planar formats:
yuv422p, yuv422p10, nv16, p210, p216
2. Implements new conversion structures and kernel definitions
for planar and semi-planar formats
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
This is in preparation for adding checkasm tests; without it,
checkasm would pull all of libavfilter in.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The drawvg filter can draw vector graphics on top of a video, using libcairo. It
is enabled if FFmpeg is configured with `--enable-cairo`.
The language for drawvg scripts is documented in `doc/drawvg-reference.texi`.
There are two new tests:
- `fate-filter-drawvg-interpreter` launch a script with most commands, and
verify which libcairo functions are executed.
- `fate-filter-drawvg-video` render a very simple image, just to verify that
libcairo is working as expected.
Signed-off-by: Ayose <ayosec@gmail.com>
To avoid pulling in the entire libavfilter when using the DSP functions
from checkasm.
The rest of the struct is not needed outside vf_idet.c and was moved there.
This commit introduces a new hardware-accelerated video filter, scale_d3d11,
which performs scaling and format conversion using Direct3D 11. The filter enables
efficient GPU-based scaling and pixel format conversion (p010 to nv12), reducing
CPU overhead and latency in video pipelines.
This filter can detect various properties about the image, including
whether or not there are out-of-range values, or whether the input appears
to use straight or premultiplied alpha.
Of course, these can only be heuristics, with "undetermined" as the base
case. While we can definitely prove the existence of full range or
straight alpha colors, we can never infer the opposite.
This patch adds the pad_cuda video filter. A filter similar to the existing pad filter but accelerated by CUDA.
The filter shares the same options as the software pad filter.
Example usage:
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i input.mp4 -vf "pad_cuda=w=iw+100:h=ih+100:x=-1:y=-1:color=red" out.mp4
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This commit adds two AMF filters: vpp_amf & sr_amf.
Both filters are using AMF hardware acceleration.
vpp_amf supports simple scaling algorithms & color conversion.
sr_amf supports advanced scaling algorithms such as FSR & can
be used for upscaling only.
The code is not currently used by libavutil, its just where our
common Vulkan code is.
Since SPIR-V compilation will be needed by lavc, move it, rather
than having lavc including lavfi.
