This is extremely long overdue for how much of a trivial process it
turned out to be to actually implement/test it. I'm embarrassed it took
us this long to get this feature, which was for several years the only
major roadblock to libplacebo replacing vo_gpu in mpv.

Note that I haven't really tested it on real data, just eyeballed the
weights to make sure it seems to be doing the right thing.

In the process of testing, I finally sobered about how all of my
idealized assumptions about the nature of temporal resampling and signal
theory were quite unpragmatic in practice. I went back to the assumption
of a ZOH world, in which frames aren't samples "centered" on themselves,
but effectively, go with the principle of least surprise by behaving the
way they would on a real LCD: start at timestamp, last until replaced.

In particular, for the convolution-based frame mixers, we assume we're
actually sampling the start of the frame, not the center of the frame.
This is, again, to avoid surprising users about their frames being
unexpectedly blurry in cases where their code is calibrated around a ZOH
world.

I originally had anticipated to have to write "helper" functions to make
calculating the correct timestamps etc. easier for the user, but I think
the current API design is so easy that such a helper function is
unnecessary.

Note that I also added a new pl_filter_mitchell_clamp to go along with
it, since clamped mitchell is what mpv's tscale also defaults to.
(Although I still think NULL is the better default)

Closes #13

Whatever.

This function could do with an extra gl_check_err, especially on the
glGetProgramBinary path, since I've observed sporadic failures of that
in the past.

It occurred to me that it really makes no sense to limit the precision
here, and it *has* bitten us in a number of ways, and also caused
general headaches in the form of needing to pass some floats as 1.0/%f
to escape the precision loss.

I seem to have completely forgotten that we actually control the float
printing code and can set the preciison to whatever we want. So just set
it as high as reasonable, because this is intended for machine consumption
anyway.

20 digits gives us enough to cover the ~16 digits of the IEEE mantissa
alongside some extra for the order of magnitude (~11 bits). This really
ought to be enough for everyone.

I can't find any wording anywhere that would imply these are somehow
*not* blendable, so I assume they just always are.

Fixes https://github.com/haasn/libplacebo/issues/89

This can differ from the image dimensions for DMA-buffers, in particular
with modifier support (i.e. for non-linear images). This is
straightforward to implement for OpenGL (although OpenGL doesn't support
3D imports), but Vulkan is still missing any sort of DMA modifier
support, so we just warn if it mismatches.

Fixes https://github.com/haasn/libplacebo/issues/88

This can speed up pl_upload_avframe() significantly, approaching zero
overhead (direct rendering) under favorable circumstances.

For pl_tex_upload, this allows us to use host pointer imports, due to
the relaxed need to ensure `ptr` can be freed after `pl_tex_upload`
returns.

For pl_tex_download, this allows us to skip the very nasty blocking
poll, as long as the user has provided some sort of callback.

Also add a test case demonstrating a nice speedup on my system (~40 fps
-> ~200 fps upload, ~160 fps -> ~200 fps download).

Closes videolan/libplacebo#123

This allows us to not only fix some of the shortcomings of pointer-based
transfers, but also make the API easier for users that need to e.g.
deref external images once an operation completes. Due to OpenGL
restrictions, this is dependent on a new GPU capability flag.

Partially implements #123

I think the status quo is that creating and destroying pl_buf should be
as cheap as possible, so there's really no point in having a separate
abstraction for somehow pooling buffers together. This is a left-over
from when `pl_buf_destroy` on an in-use buffer was undefined behaviour,
which hasn't been the case for some time now.

Removed not only because they're unnecessary, but also because the
unnecessary boilerplate is getting in the way of a planned refactor.

Big oops. Closes #122

Allocations/imports got moved from PL_INFO to PL_DEBUG, sub-allocations
(slices) got moved from PL_DEBUG to PL_TRACE.

These happen regularly enough and the code is stable enough that I don't
think it's worth spamming the log anymore.

Closes videolan/libplacebo#120

int -> init

RIP

Because this is actually a rather large release, I kinda feel it's about
time to bump the major version. I still haven't decided if I want to
switch to semver or not to avoid spilling into the three digits, but oh
well. Now it's done, anyways.

A lot of this was kinda dry and out-of-date. Modernize and expand by
emphasizing the kinda cool things libplacebo can actually do.

This is pretty trivial to support, and moves things further in
consideration of #118.

Merging the texture filter with the pl_tex object itself is a left-over
from the mpv RA days. While it involves a different set of tradeoffs, I
think it's far better overall to have this concept separate from the
texture, simply because it allows the shaders to pick their preferred
sample mode dynamically (improving performance in many cases), and in
general reduces the burden on the provider of the textures (i.e. the
user) to set this up.

In addition to splitting this from the pl_tex, we move it to
pl_desc_binding, where it can be changed at runtime. To cut down on
redundancy, we re-use pl_desc_binding for pl_shader_desc as well. Note
that `access` could also live inside pl_desc_binding in principle, but
there's no practical reason to need this because changing the access
mode requires a shader recompilation anyway.

Deprecate all the old fields rather than removing them outright, to
hopefully cut down on the amount of frustration this change will cause.
The `pl_tex_blit` function got params-ified en passant, though, which is
probably the most breaking change amidst this sea of breaking changes.

This logic was old and wrong, because params->upscaler and
params->downscaler might point to the same thing, in which case this can
end up being `true` even when downscaling.

Essentially, this would trigger if both upscaler and downscaler are set
to something like bicubic, in which case downscaling would alias.

This should be <= 4, not < 4.

VkSamplers aren't actually tied to any specific image or imageview, so
we can statically create them on pl_gpu creation and just assign the
correct sampler when updating the descriptor.

This reduces the amount of unnecessary objects per texture
creation/destruction by a grand total of one (1).

Sort of pointless at the moment, but the idea moving forwards is to also
decouple the idea of samplers from the `pl_tex` abstraction entirely.

After holding out against this function for the longest time ever, I
finally stumbled upon a justified use case for its existence:
synchronizing resource destruction of imported textures with external
libraries.

I hope I made it sufficiently clear that this function's existence does
not imply you can skip out on using pl_sync / semaphores.

Should hopefully make issues like #117 easier to debug.

As clarified by @cyanreg, FFmpeg filters are supposed to ignore
obviously "wrong" combinations, in particular RGB + limited range. We
also make an effort to clean up broken sig_peak tagging, since this
exists in practice.

I decided not to sanitize the other paramaters until I encounter a
broken file that demand it, because it's hard to draw the line
otherwise, although we could certainly come up with a few more ideas for
things that are potential candidates. (ICtCp with non-HDR curve? XYZ?)

Also clean up some whitespace because I can't be bothered making a
separate commit for it.

We over-ride this when compiling our own code, though, to avoid
triggering deprecation warnings in our own fallback paths.

As a side-note, also fix the `include` test to include the correct
config.h location.

This is motivated by these two structs, essentially, having
conglomerated into unity. Drop the deprecated fields from each and just
go ahead with the big search & replace.

This also allows us to unify a couple of helper functions, quite
pleasingly. The only really annoying thing is that `target.av1_grain`
makes zero sense, but whatever.

We also provide a new helper function to bridge the "functionality gap"
in the `pl_render_target_partial` / `pl_tex_clear` checks.

An attempt was made to preserve backwards compatibility, for what it's
worth.

The scaler code only checks whether or not the FBOFMT is storable,
but in the case of e.g. draw_overlays, we have to check the actual FBO
(provided by the user) instead.

Solve this by just checking both. (Note: In theory, if the FBO is
storable but FBOFMT is not, this would be a false negative. But
whatever.)

This is a major overhaul of the target rendering code, and the renderer
code in general (to keep things organized and understandable).

The motivation comes from vf_libplacebo, which wants to let users render
out subsampled YCbCr content directly. Unfortunately, we're still pretty
much forced to upconvert to RGB internally, if only for the sake of
things like tone mapping, linear scaling, and so forth. Plus, the entire
pl_renderer architecture is very much designed around the idea that
there's only one plane currently being rendered. While it's not entirely
impossible to change this, it'd be _way_ outside the scope of this
already massive change.

Due to the major change of a core API, I decided to make the old `pl_tex
*fbo` interface merely deprecated, rather than removing it entirely. Due
to the increasing unification between `pl_image` and `pl_render_target`,
I may choose to merge these into a single `pl_frame` at some point in
the future, but that would also imply dropping this bit of backwards
compatibility, so I'll postpone that refactor until after the next major
release.

Pick up a few bugs related to the dithering/compute indirection code
while we're at it.

Added a new test case to make sure it round trips, even for oddly-sized
planes.

Turns out we also need to clamp negative values, specifically for the PQ
function. I'm not sure if both clamps are strictly needed, but I guess
it's better to be safe than sorry.

We can go all the way back to 55.74 by dropping our reliance on
AVCOL_PRI_EBU3213. Fortunately, this is not needed, because the
backwards compatible name AVCOL_PRI_JEDEC_P22 is identical to it.

This includes libavutil-dev, so we can run the libav test.

I have no idea how this is even possible, given that sig is already
clamped to be smaller than sig_peak, but whatever. This brute-force
fixes the issue.

This replaces `int components` by a new `uint8_t component_mask`, which
is more flexible. I decided not to deprecate the original field, because
it doesn't really cause any harm to continue supporting, and in most
cases you don't need the flexibility provided by a mask, so it's just a
hassle.

Made for the sake of allowing us to more efficiently render sub-sampled
planes without needing to waste GPU time scaling unnecessary components
like luma.

The old code tried printf'ing a small float using %f, which resulted in
a rounded literal that was quite far from 1/scale. This led to the image
getting brighter than it should be, globally. The effect was very
significant for higher bit depths.

Fixed this, and improved the precision, by printing exact integer
literals, which get turned into exact float literals by the shader
compiler.

I never seem to get a break with this logic. Anyway, what happened
*this* time was that I noticed `rx`, `ry` were being incorrectly
calculated (they're supposed to be floats, but I was dividing two ints).

I also realized while working through a paper example that using `rx`
for the plane shifts was incorrect to begin with. Fortunately, for most
real-world content, `rx` and `rrx` are identical. For cases where they
aren't, the earlier answer ended up effectively cancelling out this
error, at the cost of an off-by-one (resulting in tiny, probably
unnoticed chroma misalignment).

The correct logic is to use rrx/rry for both. Fixed, and tested. (In
particular, by making sure a YCbCr image survives being converted to
RGB and back to YCbCr by the renderer)

This is technically a hack, or at the very least, some sort of
ID/UD-type behaviour. It works in practice (for good reasons), but
juuust in case, it would really be a smart idea to allow disabling it.

Also swap the order of the error messages to make sure checks happen in
a more sensible order.

After having managed to contrive in my head a scenario in which the luma
plane somehow ends up with luma in an index other than 0 (uploading UYVY
to an rgba8 texture and aliasing it as rg8, the luma information is now
in the G channel), I realized it's a good idea to support this.

It's not really a horrendeous break of API, because the backwards
compatible behaviour is, handily, what you get if you just ignore this
new field's existence.