It's a bit clumsy to mix this into pl_icc_params, but doing it here
quite elegantly avoids the need to have to plumb this through the
pl_renderer somehow, because the `pl_icc_params` are already exposed to
the user via `pl_render_params`.

Closes: videolan/libplacebo#205
Closes: https://github.com/haasn/libplacebo/issues/139

This was missing checks for `max_luma` in both `pl_icc_encode` and
`pl_icc_decode`, as well as a check for `intent` in `pl_icc_encode`.

Fix this and make it more robust by calculating the LUT signature ahead
of time. Also include the 3DLUT size in the resulting calculation, to
pave the way for the 3DLUT caching API in the next commit.

Missing check for `max_luma`. Maybe this should be moved to `icc.h` to
avoid mising updates in the future?

This has a possible divison by zero that was not guarded by the
opaqueness check. Rearrange the logic in this section to fix it.

This sort of violates some principles of thread safety by hackily
allowing the "Enable" checkbox on the deinterlacing GUI to affect
whether or not new frames are being pushed with or without deinterlacing
metadata. But any race condition here is negligible / trivial.

After a lot of internal debating and back-and-forth, I decided to settle
on an approach where the pl_queue splits up frames internally. This
frees the user from the burden of having to deal with these relatively
common corner cases, and also allows us to try and be as smart as
possible and 'do the right thing' with respect to things like doubling
detected framerate, pushing frames out-of-order, re-linking past and
future frames in all sorts of corner cases, and internally refcounting
frames on an actual as-needed basis.

This approach is relatively transparent for users and merely requires
them forward the appropriate field metadata.

It's worth pointing out that the current design of `struct entry` sort
of conflates two separate concepts: source frames, and their
corresponding fields/queue entries pointing at them. The way this is
organized internally is currently sort of ad-hoc and only done this way
to save a bit of memory and convenience. I may decide to reorganize it
in the future.

Closes: videolan/libplacebo#218

Doing deinterlacing directly in the renderer is really the only sane way
to do it, due to the following advantages:

- keeps all params in the same place
- natural frame invalidation when deinterlacing params change
- natural integration into the pl_renderer_save/load shader cache
- integration into the render stats / timings
- only deinterlaces when a frame is actually needed/used
- possibility of merging with other shader passes

Annoyingly, as a result of API limitations, we currently have to do
deinterlacing before plane merging, which is a needless slowdown. But
fixing that is a problem for another day.

For deinterlacing, we may need to know the frame duration before any
pl_queue_params has been called. Moving the frame duration to the
pl_source_frame field both matches upstream APIs better and lets us
solve this problem more elegantly.

Not currently used but will be needed for interpolation. Also fixes a
bug where we leaked the `struct entry` allocations on
`pl_queue_destroy`.

Alongside the basic/trivial deinterlacing modes, this contains an
implementation of the raw yadif deinterlacing kernel, based on
vf_yadif_cuda.cu by @philipl. Currently only supports fragment shaders,
with no compute shader speedup (although such a thing is conceptually
possible, to share duplicate sampling work between adjacent pixels).

Design the API in such a way that it permits field-merging (PAFF) should
the need should arise in the future. Also adds a few related helpers.

Closes: videolan/libplacebo#20

Failure to do so results in e.g. interplation exhausting the frame
limit. The number 4 is based arbitrarily on the maximum that doesn't
cause issues in practice.

Otherwise, cubic frame interpolation doesn't actually work. Oops.

This was accidentally double-pushing frames. Which, surprisingly, didn't
actually completely kill the implementation. But it did make it a lot
slower and also defeat the point of the test.

This warns us about the fact that we always set array pointers even when
the array count is 0, which is a pretty bogus thing to warn about.

This function was added to the API but never actually implemented.
Somebody(tm) should add a check for this...

This was clearly intended the other way around, as confirmed by the
code.

Otherwise you can't specify e.g. a black level override without also
redundantly specifying a default white level.

We currently always treat BT.1886 as a fixed 1000:1 source, which
ultimately defeats the purpose of BT.1886 to begin with, since it's
supposed to be dependent on the target viewing environment and contrast.

To fix this we need to propagate contrast information from the display
back to the image. It's worth noting that the only case in which this
immediately affects the image (in the absence of known display contrast
metadata) is in the case of mapping SDR to HDR.

I was forced to make a new function due to limitations in the existing
API of `pl_color_space_infer_ref`. This function can also do information
propagation in the target -> image direction, and conveniently also
saves a few redundant `pl_color_space_infer` calls.

Fixes: videolan/libplacebo#223
Fixes: https://github.com/mpv-player/mpv/issues/10558

With the rise of OLED displays, this choice was revealed to be an error.
A number of considerations motivate this change:

- Even affordable HDR displays are now better than 0.005 nits.
- All low-contrast HDR monitors can raise the black point to avoid
  clipping, but I don't know if OLED monitors can *lower* the black
  point of incoming signals, even with metadata.
- Metadata passthrough is still not reliable enough, even in 2022.

Defaulting to true black is a significantly safer scenario overall.

Closes: videolan/libplacebo#222
Fixes: https://github.com/mpv-player/mpv/issues/10113
See-Also: https://github.com/mpv-player/mpv/issues/10558

Implements the prior fix for the pl_renderer code path.

This commit extends pl_deband_params by an extra parameter which can be
used to tune the black point of the video. The debanding grain will be
modulated to weaken grain that would otherwise clip into this value.

Fixes videolan/libplacebo#220

1. Only deband components actually present in the pl_sample_src
2. Avoid the use of an awkward header helper functions by rewriting the
   algorithm in an in-line style

This is a minor performance gain, but mostly a refactor in anticipation
of an upcoming fix to the deband grain scaling logic.

These turn out to be quite useful in some circumstances.

In the absence of metadata fields, we absolutely should infer them to
the same values that will be used later on in the pipeline. Otherwise,
there will be massive confusion as a result of e.g. libplacebo assuming
0.005 nits for untagged HDR black, but the swapchain being configured
without a black point.

Fixes: https://github.com/mpv-player/mpv/issues/10558
Fixes: https://github.com/mpv-player/mpv/issues/10113

When using specialization constants, the shader sources no longer
contain the actual values used. This represents a challenge for
debugging, so print these out at runtime.

Hendrik Leppkes authored 2 years ago and Niklas Haas committed 2 years ago

On older Windows versions, we cannot properly test for availability of
the high bitdepth formats, and creation might fail here.

For HDR swapchains, we now write the applied metadata to
`p->color_space`.

Closes: videolan/libplacebo#217
See-Also: https://github.com/mpv-player/mpv/issues/10558

This was the intended behavior, and documented as such in mpv, but not
actually documented nor implemented in libplacebo.

Reshuffle the logic around a bit to implement things this way. Notably,
move color blindness simulation to the source space, which should
generally be a bit faster anyway because it skips linearization in many
cases.

This is needed for both mpv and VLC. Preserve the old API for
back-compat with simpler libraries like GLFW or SDL2.

Closes videolan/libplacebo#216

So, from the vulkan spec, swapchains are put into a retired state
whether the call to `vkCreateSwapchainKHR` succeeds or fails, so we
always need to garbage collect them.

In addition, the point about multiple "stale" swapchains being forbidden
is also bogus, the vulkan spec explicitly clarifies that this is
allowed.

Finally, this solves a number of theoretical race conditions that were
present as a result of this struct not being locked with respect to
callbacks, by passing the (wrapped) handle directly.

While annoying, this makes the code safe to use with all 32-bit vulkan
implementations.

Eating an extra malloc/free, while annoying, is definitely safe. This is
fortunately rather rare in practice, since we only really need it for
callbacks.