VkDevice-level pNext chains must not include any pointers to non-enabled
structures.

In theory we also shouldn't do this for VkPhysicalDevice-level
functionality, but because implementations are also required to ignore
unrecognized structs, this means a given VkPhysiclaDevice either
supports the extension (in which case it's allowed to link it) or it
doesn't (in which case it's defined to be ignored).

Turns out the ExternalBufferPropertiesKHR check was right all alone,
because that's the only *function pointer* exposed by
VK_KHR_external_memory_capabilities. Re-fix the previous "fix".

Fixes 3f197a34

This reverts commit c238c514.

Turns out that we actually need this check in order to prevent mpv from
accidentally choosing hwdec=vaapi instead of hwdec=vaapi-copy on older
drivers that don't support DRM modifiers, at the very least.

In general, the lesson learned is that we _really_ shouldn't allow
passing invalid DRM format modifiers. Users need to get this right to
use the API. That's simply the way it is.

Fixes https://github.com/haasn/libplacebo/issues/98
Fixes https://github.com/mpv-player/mpv/issues/8702
See also https://github.com/mpv-player/mpv/issues/8668

Should fix https://github.com/haasn/libplacebo/issues/92

The sdl2.pc file defines the include path including the SDL2 prefix, so
we should not have them as part of our #include statements.

This is a legal value. UNKNOWN does not mean INVALID.

No reason for this to be an obscure hex number when we can just print a
letter for each bit and get a way more readable string.

Instead of this opaque hexadecimal number for the capabilities, print
each capability with a friendly letter.

We should avoid setting any callbacks if this capability is not present.

1. Use callbacks only if they're actually supported.
2. Allow asynchronous transfers for all planes, not just the ones that
   happen to be the same plane as allocated buffers.
3. Avoid making any assumptions about the association between planes and
   buffers, since in practice this is completely false anyway.

Some types of parameter adjustments can trigger excessive shader
recompilations. In these cases, we definitely want to avoid ballooning
memory infinitely. Do something reasonable.

This handles the case of drawing overlays correctly to e.g. subsampled
YCbCr output.

Fails compiling/linking otherwise.

This is technically sort of fine as long as the display PTS is correctly
synchronized. No need to pester the user about it with a big scary
warning, necessarily. It's just something they should be aware of. DEBUG
seems like a good fit.

The queue is very much coded around the assumption that timestamps are
strictly increasing. This change enforces that.

mpv in particular likes generating small backwards jumps sometimes. In
practice, we can deal with them more or less fine - the only issue is
when we step so far back that we no longer have those frames in the
queue at all. Error in this case. In all other cases, just deal with it.

Optimizes for RGB content, especially overlays.

Just to be on the safe side.

This overflows when compiling with optimizations (or wrong arch).

Also include a minor cosmetic fix.

Oops.

(And other invalid values of `pixfmt`)

The late call to `img_tex` meant that this ran after the code that
updates `st->img.rect` based on `image->crop`. Technically, this also
resulted in minor chroma misalignment, but practically the only really
obvious breakage was when combining it with an image crop.

`meson.pc` has existed since 2 years ago. We really longer need to
manually cc.find_library() this. Also, that performance optimization
level exists since v2018.0.

I think 2 years is a good time to relax this stuff, especially after a
major release.

This is probably an API usage bug.

These can easily end up as Infinity, NaN or other magic values in the
cases where e.g. the user naively passes in values computed from streams
without known FPS, such as `plplay` currently does.

This fails for reasons beyond my comprehension. Just disable it, since
it's not useful to build code we're not going to run.

So I can tag this commit for a point release.

This is a useful enough tool that I think installing it makes sense.
(Unlike the other demos)

People that don't want it can still disable the `demos` build option.

Instead of compiling all variants of all demos, load the best backend at
runtime. Also split off the nuklear implementation into a separate
library to avoid excessively recompiling it, something that should have
been done ages ago.

This is technically a functionality downgrade, since it doesn't allow
users to choose which backend to use (Vulkan or OpenGL), instead always
picking the "best" backend. But that's mostly interesting for
developers, not users, I think.

I'll probably implement some mechanism for making that selection at
runtime, when I actually need it.

As an aside, I also renamed 'image' to 'sdlimage' since I think the name
fits better - the only reason I didn't in the past was to avoid
confusion with the suffix.

This was accidentally freed too early, causing memory corruption when
playing files with embedded ICC profiles.

Turns out I actually made this very mistake. Oops.

No reason for this confusing `demo_context()` anyway, just pick a
suitable verbosity level for each demo. In particular, `plplay` was way
too spammy.

Fuzz various patterns of creating and combining shaders, including
subshaders and various types of attached resource.

The API fuzzing is realized by iterating through a plaintext string
describing the order of operations to perform, using a simple
stack-based shader combinator language.

This function was renamewd aeons ago.

The comments were egregiously outdated. Inverted conversions *are*
supported, and so are hue/sat adjustments for everything.

These fail on 32-bit platforms otherwise.