I really, really don't remember what this bool was needed for. But it
was probably something incredibly stupid having to do with off-by-one
errors in some corner case that I can no longer reproduce.

I'll leave it this way until I can reproduce whatever bug prompted me to
add that distinction, which I suspect may have gone away with eeed2d7f.

This caused `pass_output_target` to run twice, not to mention all of the
headaches with respect to rects and scaling and so forth. The list of
bugs this fixes includes:

- No peak detection when interpolation is active
- Double application of LUTs, including conversion LUTs
- Double application of 3DLUT when force-enabling 3DLUTs (cf. #134)

This can NULL dereference if the buffer failed being created.

Rather than hard-coding gamma 2.2. This is the more reasonable thing to
do, since it allows the `avoid unnecessary gamma changes` logic to work
correctly.

This mirrors the logic used by the vulkan swapchain.

This should mirror the exact same logic used by `pl_shader_color_map`.
So move that logic to a dedicated helper function and re-use it.

Fixes a bug where wide-gamut / HDR output on OpenGL was broken out of
the box (since OpenGL defaults to UNKNOWN, a separate bug)

GLFW and SDL both provide their own platform-specific vulkan function
loading mechanisms. We should use these, instead of requiring the user
to have a linkable libvulkan at compile time.

Right now the tests all hard code checks for PL_HANDLE_FD. This breaks
on windows for obvious reasons, as well as technically with host
pointers. (Although we don't allow host pointer export anyway)

To help figure out the source of slow shader compilations.

Sampling from the base is wrong, because textureGather returns the four
texels surrounding the sampled position. What we actually want to do is
sample the center of the four texels we're interested in.

Note: While we could technically use `pos` here instead of calculating
the position dynamically, doing so seems to result in 1 pixel black
seams when combining it with some sampler modes, probably because of the
near-undefined behavior on the exact edge between pixels.

Maybe we could enable this conditionally only if we know the sampler is
set to nearest mode. But for now, just play it safe.

No change in performance. (Thankfully)

I should probably just make the log injectors public and let the avframe
helpers use them as well. But it's probably too late for that seeing as
the API has settled.

Annoyingly, this triggers a deprecation warning, which we can't really
get around because the commit that added the deprecation didn't also
change the default behavior.

Rather than the rendering framerate. Otherwise it behaves quite funnily
when e.g. resizing the window or stuff like that.

This is especially easy to trigger if the playback loop gets very stuck
(e.g. moving to a different workspace, on wayland).

Basically the issue is that `get_frame` releases `&p->lock_weak`, which
allows other threads to start pushing frames. So while `get_frame` does
ostensibly do what it claims to do on the surface (gets a frame), it
does not necessarily get exactly *one* frame, but could get 2 or 3 (or
any number).

Despite this, the logic in `advance()` was written as though `get_frame`
still got exactly one frame. Simple solution is to just change the `if`
to a `while`. Shouldn't be terribly inefficient because in practice it's
very unlikely that this will get more than 1 or 2 frames extra.

Auto-set this if we detect that the file has an alpha channel.
Annoyingly, this false positives a lot for poorly optimized PNG files
that are encoded in RGBA format despite not containing any transparency.

Otherwise, the black bars can contrast annoyingly with an otherwise
transparent media background. Inverted from the usual alpha channel
semantics to make the default value of 0.0 less surprising. (It's also a
rather unusual use case, I think)

As per the GLSL specification, sampling from a texture with an absent
alpha channel returns an alpha value of 1.0, not 0.0. We should make our
custom samplers mirror this logic, otherwise alpha channels end up
broken when using non-trivial scalers.

Fixes #150 (comment 263939)

No idea what this was doing here.

finalize_pass returns NULL on error, which should be checked by the
caller before attempting to access fields on the pass.

This avoids the issue where it's not clear where in the logs errors
happened, when looking to e.g. `meson test` (which splits stdout and
stderr).

`plplay` itself now uses EOF as a cheap way of signalling a wakeup, so
we shouldn't be too obnoxious about this case.

Even for vulkan. This is required for e.g. wayland support, or other
platforms where the swapchain size must be specified by the user.

pthread_cancel can interrupt the thread in the middle of some operations
internal to libavcodec, which causes assertion failures upon uninit.
Work around this by avoiding pthread_cancel and instead checking a bool.

Fixes videolan/libplacebo#150

This loop needs to check for p->eof, to break out of the sleep.

Document the (useful) semantics of the special value 0.5.

This replaces the previous pl_oversample_frame_mixer in a more general
way, allowing it to be used as a scale filter as well.

Very annoyingly, I couldn't figure out a better way to avoid having to
duplicate filter preset entries between the common filter.c code and the
the field from renderer.c. I'm reluctant to add pl_filter_oversample to
filter.h because it can't be used to construct normal filters.

In retrospect, I'd probably just remove `pl_filter_preset` from
`filters.h` altogether.

This is useful for pixel art and such. Also for feature parity with mpv.

FFmpeg's image2 demuxer now apparently sends still image files as
1-frame video streams with FPS 25.0, so the previous heuristic was no
longer working for more recent FFmpeg versions.

For both the VkInstance and the VkDevice. This removes the awkward
dependency on VK_KHR_get_physical_device_properties2, and instead makes
it so we can just directly use vkGetPhysicalDeviceProperties2.

For the user-provided VkInstance, merely assert() this as the case,
since *every* loader on every platform should be capable of providing an
instance at version 1.1. As for the VkDevice itself, insert an extra
error check just to be on the safe side. (And also to prevent users from
accidentally doing something stupid like limiting the api version to
1.0)

Should re-export this for pl_custom_lut etc.

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

Removing this without a deprecation was a gigantic no-no. I don't know
_what_ I was thinking. I completely forgot people actually depend on
this API (VLC, in particular).

The current semantics are a bit potentially useless in edge cases
involving only a single frame with PTS far outside the vsync range,
which unfortunately vo_placebo likes to trigger.

In a perfect world I would probably prefer to redesign this entire
abstraction with hindsight, but for the time being it's easier to just
make this small amendment.

Bump the API version mostly as a way to allow vo_placebo to depend on
this new logic (plus the previous fixes).

Similar to the corresponding commit for the frame_queue, nearest
neighbour semantics are way less fiddly than true ZOH. Basically, think
of it as trying to solve a problem of probability - which frame is most
likely to best overlap with the current frame?

In theory, an even better solution here would be to construct the
`oversample`-like semantics and then pick the frame with the highest
weight. But that's more code to write, and nearest neighbour more or
less gets the right result in practice. (I might revisit this in the
future)