The current behavior is very ad-hoc and presents numerous issues to
downstream clients. Make this configuration process more straightforward
by adding an explicit clearing mode enum field to `pl_render_params`,
which the old override fields are specific instances of.

Notably, this could be extended in the future, e.g. by PL_CLEAR_GRADIENT
or whatever. (Although this can already be done as of right now by
setting both clear modes to PL_CLEAR_NONE and using blend_params on top
of a custom-drawn gradient)

The default of `PL_COLOR_CLEAR` for both is consistent with the current
status quo, and also presents the least surprising outcome when
combining transparent/opaque images with transparent/opaque
framebuffers. This way, the user only gets transparent images output if
they explicitly opt-in to it, either by setting
`background_transparency` to 1 (like `plplay` does), or by setting the
background clearing mode to `PL_CLEAR_SKIP`.

In particular, `border = PL_CLEAR_SKIP` will result in "garbage" pixels
out of the box, at least on implementations which don't pre-clear
framebuffers for you.

Supersedes: videolan/libplacebo!637

Analog to pl_frame_clear_rgba. I had to decide carefully whether
I wanted to preserve the symmetry with `pl_frame_clear_rgba` in taking
only a `pl_gpu`, or if I should take the whole `pl_renderer` to gain
access to the internal `pl_dispatch`. But I decided to go with the
`pl_gpu`, since we might want to move this set of functions to
a different module in the future. (It's not really renderer-specific)

I also really regret having to go through such hoops every time to get
the per-plane subsampling ratio. Truthfully, this should probably be
a helper function.

See-Also: videolan/libplacebo!637

This field was doing double duty between marking the alpha mode as
unknown and marking the alpha channel as absent, with inconsistent
results. In particular, pl_renderer always inferred the alpha channel if
present in the texture, leaving users with no options for easily
manually disabling it.

This patch adds PL_ALPHA_NONE to rectify the situation, allowing API
users to set `target.repr.alpha = PL_ALPHA_NONE` to explicitly disable
alpha blending even when the target supports it.

See-Also: videolan/libplacebo!637

Relaxes some restrictions on this function, but also reduces the
tendency of this pass to introducing blurring/smudging.

Fixes: https://github.com/mpv-player/mpv/issues/13399

Convenience function, we don't care about pl_frame here.

Also deprecate pl_frame_map_avdovi_metadata to reduce API surface in
future, both functions do the same thing. Prefer the one with relaxed
API.

They apparently like to randomly remove them. Just mark them as not
required.

Fixes: videolan/libplacebo#321

Fixes warning:
`integer modulus may be much slower, try using uints if possible`

Fixes: b2b61a75

Unrolling fully doesn't bring performance gain and makes shaders huge
and heavy to compile.

Also this avoid recompiling shader when kernel size changes, because it
is not dynamic variable.

Comparision on Ryzen 7950x.

Before:

Spent 27.292 ms translating SPIR-V
Spent 1317.319 ms translating SPIR-V (slow!)
Spent 0.052 ms compiling shader
Spent 67.641 ms creating pipeline

After:

Spent 28.963 ms translating SPIR-V
Spent 77.494 ms translating SPIR-V
Spent 0.043 ms compiling shader
Spent 0.199 ms creating pipeline

Note it is done twice, for vertical and horizontal kernel. On top on
some platforms there is additional step to translate SPIR-V to another
format like DXBC.

In an atempt to mitigate some users having excessive compilation times
for no good reason.

See: https://github.com/mpv-player/mpv/issues/12753

Rather than requiring exact pointer equality. This should enable such
fast paths to work transparently with callers like mpv that always
construct their own pl_filter_config struct.

Fixes: a5e70102

Fixes: a5e70102

Fixes mapping Vulkan P010 frames.

Closes #237

Fixes: https://github.com/haasn/libplacebo/issues/234

These are part of GLES 3.0, there is no extension for them.

This patch prevents a segmentation fault that occurs when size_base is
not a multiple of max_transfer. If size_base is larger than the
max_transfer value but is not a multiple of it, the last iteration of
the loop will transfer too much. It needs to transfer how much is
remaining of size_base.

Note that the PL_MIN behaves identically when size_base is less than
max_transfer, because xfer will never be nonzero in that scenario.

Signed-off-by: Leo Izen <leo.izen@gmail.com>

David Rosca authored 1 year ago and Niklas Haas committed 1 year ago

Fixes mapping frames with padding (eg. 1080p ~ 1088).

Not the correct solution, but an improvement on the status quo.

See-Also: #319

No need to include xxhash dependency in .pc, it is fully inlined.

By comparing signature before and after loading.

This is technically redundant with pl_cache_iterate() and simply
performing the XOR yourself, but much more efficient and convenient.

Small keys break some statistical assumptions inside the cache layer.

This was accidentally included once per sample, as a result of the
anti-ringing code.

See-Also: https://github.com/haasn/libplacebo/issues/217

$id@c can collide with another identifier that has larger $id, add extra
_ to avoid collision.

Fixes: https://github.com/haasn/libplacebo/issues/217

pl_icc_update needs to be called every frame, so if libplacebo is
compiled without lcms support, this leads to spam. There's no need to
warn more than once so just keep track of it in a bool.

These should have gone through a deprecation period, since they are
a public API.

Fixes: dcd5b75b
Fixes: vlc#28417

At least for mpv, if we have a playlist of images, fail opening the ICC
of one image, go forward and then back to the image with the ICC
failure, it'll hit this assertion failure. Not so nice. If there's no
ICC information, it just does nothing so display the image as usual.

By default, allows for correcting drift/jitter of up to 1 ms per frame,
in line with expected jitter from e.g. Matroska sources. This is enough
to cover the mismatch between 23.976 Hz and 24.000 Hz, but not the
mismatch between 24 and 25 Hz (which is just over 1ms per frame).

There are two use cases in which this code will be useful:

1. Displaying 23.976 Hz video files on e.g. 60.000 Hz monitor (or any
   other near-miss), in display-timed mode. Given the usual 3:2
   cadence, after five vsyncs (three source frames), we will have:

   Vsync (wallclock) PTS = 83.33333333333334
   Frame PTS = 83.41675008341676

   This is a difference of 0.1ms, and will therefore be fixed by this
   code, adjusting all future wallclock PTS up by the cumulative drift
   (0.1ms).

2. Displaying any video with some amount of jitter on the PTS
   measurements. This avoids some situation where we have frames with
   weights 0.999 and 0.001 for example. Normally this should get rounded
   away by the frame mixing code anyway, but it's better to have an
   exact match.