This was accidentally inverted...

It's called pl_render_*DEFAULT*_params for a reason.

Code 95% generously donated by ChatGPT. Bugs in remaining 5%.

What a headache this file was growing into...

Testing revealed the LUT size of 256 to have no performance downside
compared to 64, and it still fits into the hard limit for literal LUTs.
The maximum error (at ~1000x upsampling) is also on the order of 1e-4,
far surpassing any threshold of perceptibility.

Similarly, 1e-3 polar cutoff is not only completely below the dithering
noise floor at 8-bits SDR, but also below JND (~10 bits). Going any
higher than this starts to lead to visible/measurable artifacts, and
going any lower is just slower for no benefit.

Reducing option bloat, one commit at a time.

Useful for benchmarking e.g. scalers on still images.

Should really have been part of the previous API bump, but oh well. We
can't support this easily in the pl_frames_infer() case, and it's also
not used by any downstream client currently. It's much simpler to just
set ICC profiles to NULL.

Re-gains us the functionality of pl_icc_params.

Addition of the pl_cache means we now persist ICC 3DLUTs across
restarts, in which case we seriously need to use the actual hash of the
profile to identify ICC profiles. Otherwise there will be cache
collisions all over the place.

Fixes: b38e1c84

Allows forcing the use of a scale pass to force all residual subpixel
offsets, instead of implicitly ignoring them.

Closes: #291
Closes: https://github.com/mpv-player/mpv/issues/11948

For debugging purposes.

With xxhash, 50 MB is plenty fast enough compared to the general vulkan
init etc. overhead, and gives us plenty of room to store a number of ICC
3DLUTs and gamut mapping 3DLUTs.

xxhash is fast enough to not really worry about a few-MB large objects
slowing down init process.

For debug purposes.

Probably won't work for ICC/3DLUT cache but these probably want their
own custom mechanism anyway, since they're quite large.

To be logarithmic.

This is the wrong layer to solve this problem, and in particular,
hard-coding SDR 1.0 here prevents tone-mapping e.g. 200 nits scene to
50 nits projector. No longer needed hack now that we clamp in the tone
mapper directly.

See previous commit.

Allows scaling down the intensity of the saturation mapping step.

Sigh, no real recourse other than to brute force the mapping.

Still need to add a custom UI for the advanced tunables, but I'll defer
that to a future commit.

To completely disable smoothing, since even a smoothing period of 1.0
implies a small amount of smoothing.

This does technically regress the status quo behavior when passing 0
(which would previously see it being defaulted to 100), but with the way
options are handled these days (via the PEAK_DETECT_DEFAULTS macros) I'm
hoping to phase out the use of such implicit defaults to begin with.

It also doesn't break any current client (I checked all).

For convenience.

Doesn't actually amount to much of a change because we were already
doing the equivalent of this internally. Just allows us to delete some
boilerplate.

Minor extra boilerplate needed to early-initialize the log.

In retrospect I have no idea why I bothered with the complicated old
implementation of this logic to begin with.

By default, show only recomended filters for each usage type; hide the
rest behind an advanced checkbox.

Off by default to avoid expanding gamut unless requested.

This has gotten a lot more sophisticated over the years, for better or
worse.

"Insufficient decoding speed" can also happen due to other reasons such
as the frame mixing method suddenly changing.

Code is clear enough without it.

Perfectly synchronizes start of playback with the start of the virtual
PTS timeline, excluding the time taken in between measurement of
`ts_start` and measurement of the first `ts_pre_update`.

Sure, this is probably only a few nanoseconds, if the timer can even
resolve it. But still.

I first wanted to make a nice graph here like with the shader stats but
eventually bikeshedding got the best of me and I decided to just delete
it because I couldn't figure out a clean way to integrate it into the
nuklear interface.

Besides, not needing to draw a graph vastly simplifies this already
overly-verbose debugging / logging code.

It's a misnomer because it's the timestamp before calling
pl_queue_update().

Inverts the order of operations to render first, then wait until the
target PTS. This is a much better way to do things as it lowers the
effective latency and jitter that would otherwise be added by the
rendering time.

This can happen legitimately in the case of EOF or single frame media,
in which case fallback to the current behavior (untimed mode) is fine.

Partially-Fixes: !506

Will be useful for implementing this on other platforms.