| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Fairly straightforward. We just need to modify the scaler handling code
slightly to support looking at a different list of filter presets.
|
| |
|
|
|
|
|
|
|
|
|
| |
This exposes libplacebo's frame mixing functionality to vf_libplacebo,
by allowing users to specify a desired target fps to output at. Incoming
frames will be smoothly resampled (in a manner determined by the
`frame_mixer` option, to be added in the next commit).
To generate a consistently timed output stream, we directly use the
desired framerate as the timebase, and simply output frames in
sequential order (tracked by the number of frames output so far).
|
| |
|
|
|
|
|
|
|
| |
To present compatibility with the current behavior, we keep track of a
FIFO of exact frame timestamps that we want to output to the user. In
practice, this is essentially equivalent to the current filter_frame()
code, but this design allows us to scale to more complicated use cases
in the future - for example, insertion of intermediate frames
(deinterlacing, frame doubling, conversion to fixed fps, ...)
|
| |
|
|
|
|
| |
This does not leverage any immediate benefits, but refactors and
prepares the codebase for upcoming changes, which will include the
ability to do deinterlacing and resampling (frame mixing).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit contains no functional change. The goal is merely to
separate the highly intertwined `filter_frame` and `process_frames`
functions into their separate concerns, specifically to separate frame
uploading (which is now done directly in `filter_frame`) from emitting a
frame (which is now done by a dedicated function `output_frame`).
The overall idea here is to be able to ultimately call `output_frame`
multiple times, to e.g. emit several output frames for a single input
frame.
|
| |
|
|
|
|
| |
Only update this struct when it's expected to change, and cache it
otherwise. Partially motivated by a desire to make `process_frames`
smaller.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recent versions of libplacebo have required Vulkan versions incompatible
with lavu Vulkan hwcontexts. While this is expected to change
eventually, breaking vf_libplacebo every time there is such a transition
period is obviously undesired behavior, as the following sea of bug
reports shows.
This commit adds a fallback path for init_vulkan failures which simply
creates an internal device if there was no user-supplied Vulkan hwaccel.
Useful when no interop with lavu vulkan hwframes is needed or desired,
and makes using this filter easier inside certain applications.
Fixes: https://github.com/haasn/libplacebo/issues/170
Fixes: https://github.com/mpv-player/mpv/issues/9589#issuecomment-1535432185
Fixes: https://github.com/mpv-player/mpv/issues/11363
Fixes: https://github.com/mpv-player/mpv/issues/11685#issuecomment-1546627082
Closes: https://code.videolan.org/videolan/libplacebo/-/issues/270
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Motivated by a desire to use vf_libplacebo as a GPU-accelerated
cropping/padding/zooming filter. This commit adds support for setting
the `input/target.crop` fields as dynamic expressions.
Re-use the same generic variables available to other scale and crop type
filters, and also add some more that we can afford as a result of being
able to set these properties dynamically.
It's worth pointing out that `out_t/ot` is currently redundant with
`in_t/t` since it will always contain the same PTS values, but I plan on
changing this in the near future.
I decided to also expose `crop_w/crop_h` and `pos_w/pos_h` as variables
in the expression parser itself, since this enables the fairly common
use case of determining dimensions first and then placing the image
appropriately, such as is done in the default behavior (which centers
the cropped/placed region by default).
|
| |
|
|
|
|
| |
In some circumstances, libplacebo will clear the background as a result
of cropping/padding. Currently, this uses the hard-coded default fill
color of black. This option makes this behavior configurable.
|
| |
|
|
|
|
|
|
|
|
| |
Not doing so is an obvious oversight - the ICC profile is tied to the
original colorspace, so if we change it, we should definitely strip this
information.
We should probably also have an extra option to control whether the ICC
profile should be stripped, ignored, or applied, but for now this fixes
an existing bug.
|
| |
|
|
|
| |
This way the caller can set it just on the filters that can make use of
it.
|
| |
|
|
|
|
|
|
|
|
| |
This has not been functional since a year ago, including in our current
minimum dependency of libplacebo (v4.192.0). It also causes build errors
against libplacebo v6, so it needs to be removed from the code. We can
keep the option around for now, but it should also be removed soon.
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: James Almer <jamrial@gmail.com>
|
| |
|
|
|
| |
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: James Almer <jamrial@gmail.com>
|
| |
|
|
| |
libplacebo gained these exciting new functions upstream.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to construct the output format list separatedly from the input
format list, because we need to adhere to two extra requirements:
1. Big-endian output formats are always unsupported (runtime error)
2. Combining 'vulkan' with an explicit out_format that is not supported
by the vulkan frame allocation code is illegal and will crash (abort)
As a free side benefit, this rewrite fixes a possible memory leak in the
`fail` path that was present in the old code.
Signed-off-by: Niklas Haas <git@haasn.dev>
|
| |
|
|
| |
This warning was introduced when ee65039 removed the cast.
|
| |
|
|
|
| |
Before this, the filter blindly casts to AVVulkanDeviceContext and
passes invalid values to libplacebo if it's not.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than hard-coding AV_PIX_FMT_VULKAN, expand this to the full list
of formats supported by <libplacebo/utils/libav.h>. We re-use the
existing `format` option to allow selecting specific software formats in
addition to specific vulkan hwframe formats.
Some minor changes are necessary to account for the fact that
`ff_vk_filter_config_output` is now only called optionally, the fact
that the output format must now be parsed before `query_format` gets
called, and the fact that we need to call a different function to
retrieve data from the `pl_frame` in the non-hwaccel case.
Signed-off-by: Niklas Haas <git@haasn.dev>
|
| |
|
|
|
|
|
|
| |
This previous expression multiplied a constant (outlink->h) that was
guaranteed to be 0 at this point, thus making it always a no-op.
Fix the calculation, and also properly reset the SAR to 1:1 as is now
necessary (the failure to do so previously hid this bug's existence).
|
| |
|
|
|
|
|
|
|
| |
As a result of a typo in the source code, this option was completely
non-functional. In order to fix it, without breaking the current default
behavior, explicitly change this default to 0.
This behavior is also consistent with how other scale filters behave by
default, so it's probably best to enshrine it anyways.
|
| |
|
|
|
|
|
|
|
|
| |
After commit c0b93, it's possible that `ff_vk_filter_config_input` never
gets called, leading to `s->vkctx.input_format` being left unset. This
broke the format auto-selection logic in `libplacebo_config_output`,
resulting in a default to yuv420p, instead of defaulting to the input
format as intended.
Fixes: c0b93c4f8be48e2abad1eb5358643a01b9e27613
|
| |
|
|
| |
Move the declaration before the code.
|
| |
|
|
|
|
|
|
|
|
| |
This is done only to the inputs, not the outputs, because we always
output vulkan hwframes.
Doing so also requires keeping track of backing textures for non-hwdec
formats, but is otherwise a mostly straightforward change to the format
query function. Special care needs to be taken to avoid crashing on
older libplacebo due to AV_PIX_FMT_RGBF32LE et al.
|
| |
|
|
|
|
| |
Instead of doing it ad-hoc in `filter_frame`. This is not a huge change
on its own, but paves the way for adding support for more formats in the
future, in particular formats other than AV_PIX_FMT_VULKAN.
|
| |
|
|
|
| |
Reviewed-by: "mypopy@gmail.com" <mypopy@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
| |
|
|
|
|
|
|
| |
This makes the filters match their declaration in
libavfilter/allfilters.c; the earlier discrepancy was btw UB.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Upstream gained a new tone-mapping API, which we never switched to. We
don't need a version bump for this because it was included as part of
the v4.192 release we currently already depend on.
Some of the old options can be moderately approximated with the new API,
but specifically "desaturation_base" and "max_boost" cannot. Remove
these entirely, rather than deprecating them. They have actually been
non-functional for a while as a result of the upstream deprecation.
Signed-off-by: Niklas Haas <git@haasn.dev>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This was accidentally comparing s->colorspace against out->colorspace,
which is wrong - the intent was to compare in->colorspace against
out->colorspace.
We also forgot to strip mastering metadata. Finally, the order is sort
of wrong - we should strip this side data *before* process_frames,
because otherwise it may end up being seen and used by libplacebo.
Signed-off-by: Niklas Haas <git@haasn.dev>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
libplacebo supports automatic dolby vision application, but it requires
us to switch to a new API. Also add some logic to strip the dolby vision
metadata from the output frames in any case where we end up changing the
colorimetry.
The libplacebo dependency bump is justified because neither 184 nor 192
are part of any stable libplacebo release, so users have to build from
git anyways for this filter to exist.
Signed-off-by: Niklas Haas <git@haasn.dev>
|
| |
|
|
|
|
|
|
| |
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 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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
