May be useful for debugging.

Shocking, I know.

Motivated by !643, but also generally useful.

Since this is very restricted on non-resizable BAR platforms.

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: !637

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.

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

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

Fixes: dcd5b75b
Fixes: vlc#28417

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.

Fixes unnatural black flickering in some scenes where encoding noise
pushes the background between 0 and 1 PQ. Adding a 1% PQ cutoff allows
censoring such values to 0.

I could also have hard-coded this constant but I decided it's simple
enough to expose, and it being tunable may help with tracking down
related issues in the future, and also allows users to opt out of this
functionality altogether.

Fixes: https://yabb.jriver.com/interact/index.php/topic,136378.msg950343.html#msg950343

llyyr authored 1 year ago and Niklas Haas committed 1 year ago

This would break build because _XOPEN_SOURCE works differently on
FreeBSD than on Linux, so just remove it since it's not needed.

For next release.

"Nearest" is a misnomer when applied to downscaling. To resolve this
confusion, make "nearest" work for upscaling only and add a "box" alias
that works for downscaling as well.

This was accidentally set to the same as PL_FILTER_UPSCALING.

And store these values to pl_filter.radius and pl_filter.radius_cutoff,
even for ortho filters. Deprecate the now redundant radius_cutoff.

Will probably be helpful if we ever want to use main lobe antiringing
for ortho scalers as well. Also improves accuracy of the LUTs, and
allows using smaller LUTs for ortho scalers that have large regions of
mostly zero.

Finally, this is a very slight performance improvement to ortho
downscaling with extreme ratios, since we can round up to a smaller
integer multiple. Probably not very relevant in practice.

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.

To bypass host pointer importing, for debugging and in some situations
where doing so would lead to quickly exhausting 4G limit.

These are easy to generate for specific, fixed, always positive shaders
based on the same principle.

Kacper Michajłow authored 1 year ago and Niklas Haas committed 1 year ago

We never check errno for math function and they are faster when not
setting it.

This matches HermiteFilter from ImageMagick (B=C=0 and R=1).
Make it a recommended frame mixer, as well as the default for the high
quality profile instead of clamped mitchell.

Changes params for bcspline/cubic filter function to B=1, C=0 to match
CubicFilter in ImageMagick.

Since the new bcspline params ended up making it the same as
bicubic, merge the two as pl_filter_function_cubic and add both as an
alias to cubic.

This also removes pl_filter_function_{bicubic, bcspline, catmull_rom,
mitchell, robidoux, robidouxsharp}.

Useful to give clients the ability to figure out exactly what colorspace
parameters and crop positions will be used during rendering, without
having to guess or duplicate logic.

Supersedes: !557

Often duplicated inside mpv/vf_libplacebo, and soon to be re-used inside
renderer.c also.

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.

So, there are a number of things that motivate this:

1. Using the same ICC profile settings for both the display and the
   image is rather confused, especially with regards to `max_luma`
   handling. (see #302)
2. Forcing a specific 3DLUT size for both is also wrong, since most
   image ICC profiles are very simple to describe and do not require
   large 3DLUTs.
3. The dependency of `icc_fallback` on `pl_render_params` breaks our
   ability to provide !575.
4. I don't like the ad-hoc cache stuff leaking its way into
   pl_render_params (and especially being incompatible with pl_options)

Fixes: #302

Augments the more clunky pl_frame.profile with an explicit API that
allows the user to initialize the ICC object externally.

I decided not to deprecate `pl_frame.profile` for now, because
*requiring* the use of the new API would make e.g. the libav wrappers
much more difficult to write, since they would now need to maintain
external state somehow.

Yet more reasons `pl_frame` should always have been a heap-allocated
object, so we can just tie the lifetime of the ICC profile to it...

To recreate an ICC profile only if it changed. Mirrors the logic inside
`update_icc` of pl_renderer, except with the addition of the ability to
directly re-use an already-opened profile, skipping the need to keep
this profile loaded persistently.

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

We no longer support running MSAN without fully instrumented
dependencies at all, either in the CI or otherwise. So, no more need for
all these hacks.

It was fun while it lasted.

Caching is now done directly inside the pl_gpu, via the pl_cache
mechanism. This cache layer is no longer functional or needed.

Redirect the calls for backwards compatibility, although this will
still regress API users who do not set `pl_cache` explicitly.

No longer functional after the recent changes to make pl_gpu use
pl_cache directly. No need for backwards compatibility because there is
basically no user of this API in the wild.

Now users can be explicit about which cache they want to use, with the
save/load callbacks being used as a fallback for backwards
compatibility (for now).

Allows attaching custom pl_cache to a pl_gpu.

Motivated by #299

This mechanism should be more pluggable and less opaque than the
previous ad-hoc dispatch cache, and gives the user better control over
exactly when and where stuff is cached (or not).

I will eventually also add an internal file-based cacher to serve as an
example cache_cb, but that is a plan for the future.