Using `libdovi` to parse the RPU, as `AVDOVIMetadata`
does not yet parse the extension metadata blocks.

This generally produces good results in such a case. ST2094-40 is better
than ST2094-10 even in the absence of metadata, because the relevant
parts of ST2094-10 (the average->average mapping) are also implemented
in the ST2094-40 fallback path, and more importantly, the latter also
implements proper black point adaptation (to avoid black crush).

In the future, ST2094-40 (possibly with some tweaks) might become the
one-size-fits-all default tone-mapping method for all scenarios.

The implementation for ST2094-10 is straightforward by just copying
equations from the corresponding SMPTE document. While this relies on
metadata for the best results, we can get good enough results by just
taking the avg to be 10.

For ST2094-40, includes modifications from the ATSC A/341 amendment. I
had to omit the section about fixing the first bezier point (P[1]),
because it resulted in a completely broken output for some samples (due
to extreme slopes in the knee function). Also includes black point
adaptation, based on specification BT.1886 - something that was notably
missing in the original SMPTE spec.

Omits the parts of the spec we can't faithfully implement, such as the
detail processing BS, support for overlapping elliptical windows, and
the ST2094-10 subjective gain/offset controls missing in HDR10+
metadata.

Closes: videolan/libplacebo#244
Closes: videolan/libplacebo#245

In SMPTE ST2094-40, it recommends applying an extra gain parameter to
raise the brightness of very monochromatic scenes when using
PL_TONE_MAP_MAX. Implement this spec using the hard-coded reference
values.

When HDR metadata is present, because this is expected to change
semi-frequently.

By just sticking it inside `pl_hdr_metadata`, happen what may.

We don't need access to the output metadata, so omit it. (This will
probably never change, because this HDR metadata contains scene-derived
values)

This not only exposes the previous logic to users, but also adds support
for AVDynamicHDRPlus. Use this function internally in place of the
previous duplicated code, and also get rid of some sanity masking logic
that was of dubious importance (especially now that `nominal_min/max`
are decoupled from the HDR metadata).

For HDR10, we only map the fields relevant/interesting for us, ignore
the rest. (Which is also unused in practice)

Prefix this #define

Redundant in this case, since the per-scene values are both
authoritative and significantly more accurate.

So, I was growing increasingly dissatisfied with the need to override
the HDR mastering display metadata for PQ inputs, and wanted to cleanly
separate concerns here.

After this refactor, the *mastering metadata* remains purely
informative, and all of the relevant defaulting logic goes on inside
`pl_color_space`. This field will also be consulted for any operations
relevant to tone-mapping, and can take into account both per-scene
metadata as well as static metadata.

As an aside, I decided to just completely drop back-compatibility with
the deprecated `sig_*` fields, because it's been years.

Based on SMPTE ST2094, and in particular A/341 ATSC 2094-40. We should
keep track of this so we can add it to the metadata and use it for
things like ST2094-10 and ST2094-40.

We don't default these value if missing, because their presence should
indicate the availability of frame-specific metadata.

Based on FFMAX3

There is 4 bytes padding in `pl_hook` struct, which makes MSAN unhappy
when we do `pl_mem_hash` on `pl_hook`. Just init this padding to zero.

This fixes memory leak of frames which had ref count initialized to 0
and `pl_rc_deref` would never return true, because it compares to 1.

Affects only deinterlacing.

The layout of variables inside an SSBO is implementation-defined making
it not really safe to use without layout specification, which is
supported on GLSL >= 140.

To make leak detectors happy

This fixes error on 4.1:
error: initializer of const variable `pos' must be a constant expression

To fix warning implicit conversion from 'int' to 'float' changes value
from 2147483647 to 2147483648...

Also add cast to uint8_t which is inline with usage of this macro

This one is a false positive, so just add an assert to silence it.

It doesn't like referencing values as part of the same struct
initialization.

Needed to load gl->GetProgramResourceIndex on GL <4.3.

Fixes: videolan/libplacebo#246

This is probably nonsensical, since the plane swapping only happens
inside `pl_upload_plane`.

Test for both 3- and 4-component formats, which ought to cover the lot.

Make a number of changes to this logic in the hopes of picking stupid
combinations (like device-local host-cached memory, or host-local shader
storage buffers) less often.

Fixes: 8a8d8456
Fixes: https://github.com/mpv-player/mpv/issues/11270

These two formats currently result in an assertion failure due to being
encoded in a format that implicitly assumes 32-bit word aligned
sampling. Worryingly, there's no way to tell (in libavutil), whether or
not we're dealing with such a format or a "normal" big endian format.

So simply detect this case by looking for "shifted" components.

We call vkDestroySurfaceKHR indiscriminately, even if VK_KHR_surface was
not even enabled. (Since it's listed under `opt_extensions`, this is a
valid case)

Easiest way to work around this special case is to just avoid calling
vkDestroySurfaceKHR if we never created a surface, since in that case
`surf` will still be NULL.

Kacper Michajłow authored 2 years ago and Niklas Haas committed 2 years ago

All those values need to be handled and removing defualt case enables
compiler warning if something is missing.

Also remove int cast from DXGI_FORMAT switch, it is not needed there.

Kacper Michajłow authored 2 years ago and Niklas Haas committed 2 years ago

Fixes some compilation warnings.

Kacper Michajłow authored 2 years ago and Niklas Haas committed 2 years ago

Supresses warning about no return value from main()

Insteand if printing big negative duration just skip it. Add TBR and TBN
print.

Works around an llvmpipe crash in the latest version of mesa.

See-Also: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8203

Now we can finally actually compile this code. Yayifications?