This was renamed upstream quite a while ago (v3.112.0). Rename the
option name as well for consistency (and expand the description just
slightly).
Signed-off-by: Niklas Haas <git@haasn.dev>
Support for mapping/unmapping hardware frames has been added into
libplacebo itself, so we can scrap this code in favor of using the new
functions. This has the additional benefit of being forwards-compatible
as support for more complicated frame-related state management is added
to libplacebo (e.g. mapping dolby vision metadata).
It's worth pointing out that, technically, this would also allow
`vf_libplacebo` to accept, practically unmodified, other frame types
(e.g. vaapi or drm), or even software input formats. (Although we still
need a vulkan *device* to be available)
To keep things simple, though, retain the current restriction to vulkan
frames. It's possible we could rethink this in a future commit, but for
now I don't want to introduce any more potentially breaking changes.
The following command is on how to apply cclock option:
ffmpeg -init_hw_device vulkan -i input.264 -vf \
hwupload=extra_hw_frames=16,transpose_vulkan=dir=cclock,hwdownload,format=yuv420p \
output.264
The following command is on how to apply clock_flip option:
ffmpeg -init_hw_device vulkan -i input.264 -vf \
hwupload=extra_hw_frames=16,transpose_vulkan=dir=clock_flip,hwdownload,format=yuv420p \
output.264
The following command is on how to apply clock option:
ffmpeg -init_hw_device vulkan -i input.264 -vf \
hwupload=extra_hw_frames=16,transpose_vulkan=dir=clock,hwdownload,format=yuv420p \
output.264
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
The following command is on how to apply transpose_vulkan filter:
ffmpeg -init_hw_device vulkan -i input.264 -vf \
hwupload=extra_hw_frames=16,transpose_vulkan,hwdownload,format=yuv420p output.264
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
These lists have size fields since
e48ded8551.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This filter flips the input video both horizontally and vertically
in one compute pipeline, and it's no need to use two pipelines for
hflip_vulkan,vflip_vulkan anymore.
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
Fixes a mistake in dea673d0d5.
GCC emitted a -Wint-in-bool-context warning because of that.
Reviewed-by: Soft Works <softworkz@hotmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The following command is on how to apply vflip_vulkan filter:
ffmpeg -init_hw_device vulkan -i input.264 -vf hwupload=extra_hw_frames=16,vflip_vulkan,hwdownload,format=yuv420p output.264
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
The following command is on how to apply hflip_vulkan filter:
ffmpeg -init_hw_device vulkan -i input.264 -vf hwupload=extra_hw_frames=16,hflip_vulkan,hwdownload,format=yuv420p output.264
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
The issue is that libavfilter depends on libavcodec, and when doing a
static build, if libavcodec also includes "libavfilter/vulkan.c", then
during link-time, compiling programs will fail as there would be multiple
definitions of the same symbols in both libavfilter and libavcodec's
object files.
Linkers are, however, more permitting if both files that include
a common file that's used as a template are one-to-one identical.
Hence, to make both files the same in the future, export all avfilter
specific functions to a separate file.
There is some work in progress to make templated files like this be
compiled only once, so this is not a long-term solution.
This also removes a macro that could be used to toggle SPIRV compilation
capability on #include-time, as this could cause the files to be different.
Whether failed or not, the block of codes labeled with fail should
be always run to ensure the av_free(kernel_def) is executed.
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
This commit adds a powerful and customizable gblur Vulkan filter,
which provides a maximum 127x127 kernel size of Gaussian Filter.
The size could be adjusted by requirements on quality or performance.
The following command is on how to apply gblur_vulkan filter:
ffmpeg -init_hw_device vulkan -i input.264 -vf hwupload=extra_hw_frames=16,gblur_vulkan,hwdownload,format=yuv420p output.264
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
There is no reason to wrap them in #ifndef guards, they should only be
defined here and nowhere else. The define guards just add the
possibility to accidentally use the same FF_API name in different
libraries.
Unfortunately pad_len and pad_dur behaviour was different if 0 was specified,
pad_dur handled 0 duration as infinity, for pad_len, infinity was -1.
Let's make the behaviour consistent by handling 0 duration for pad_dur and
whole_dur as indeed 0 duration. This somewhat changes the behaviour of the
filter if 0 was explicitly specified, but deprecating the old option and adding
a new for the corrected behaviour seemed a bit overkill. So let's document the
change instead.
Signed-off-by: Marton Balint <cus@passwd.hu>
In particular, allows users to go all the way up to PL_LOG_TRACE if
desired. (While also avoiding some potentially unnecessary callbacks for
filtered messages, including e.g. the CPU cost of printing out shader
sources)
Response to runtime log level changes by updating it once per
filter_frame(), which should hopefully be often enough.
This filter conceptually maps the libplacebo `pl_renderer` API into
libavfilter, which is a high-level image rendering API designed to work
with an RGB pipeline internally. As such, there's no way to avoid e.g.
chroma interpolation with this filter, although new versions of
libplacebo support outputting back to subsampled YCbCr after processing
is done.
That being said, `pl_renderer` supports automatic integration of the
majority of libplacebo's shaders, ranging from debanding to tone
mapping, and also supports loading custom mpv-style user shaders, making
this API a natural candidate for getting a lot of functionality out of
relatively little code.
In the future, I may approach this problem either by rewriting this
filter to also support a non-renderer codepath, or by upgrading
libplacebo's renderer to support a full YCbCr pipeline.
This unfortunately requires a very new version of libplacebo (unreleased
at time of writing) for timeline semaphore support. But the amount of
boilerplate needed to hack in backwards compatibility would have been
very unreasonable.
