This makes those headers included with -isystem rather than -I,
which makes the compiler skip producing any warnings about them
(as they're expected to be out of the user code's control).
This avoids warnings with newer versions of the
dav1d-debian-unstable CI image, warnings (treated as errors in CI)
like this:
In file included from /usr/include/SDL2/SDL_config.h:51,
from /usr/include/SDL2/SDL_stdinc.h:33,
from /usr/include/SDL2/SDL_main.h:25,
from /usr/include/SDL2/SDL.h:31,
from ../examples/dav1dplay.c:33:
/usr/include/SDL2/SDL_config_unix.h:186:9: error: 'HAVE_GETAUXVAL' redefined [-Werror]
186 | #define HAVE_GETAUXVAL 1
| ^~~~~~~~~~~~~~
In file included from ../examples/dav1dplay.c:27:
./config.h:66:9: note: this is the location of the previous definition
66 | #define HAVE_GETAUXVAL 0
| ^~~~~~~~~~~~~~
Recently, Debian Unstable has switched from providing the
actual SDL 2 to providing the SDL 2 API through the sdl2-compat
package on top of SDL 3.
The SDL 2 headers expose their full config.h as part of their
installed headers (that the user code ends up including). This
includes unnamespaced defines, such as "#define HAVE_GETAUXVAL 1".
This issue hasn't shown up with the original SDL 2 package in
Debian, due to a Debian packaging detail. While most SDL 2
headers are installed in /usr/include/SDL2 (and user code
includes it as <SDL.h>, requiring the build system to include
/usr/include/SDL2), the Debian packaging has replaced
/usr/include/SDL2/SDL_config.h with a header that includes
<SDL2/_real_SDL_config.h>, which then gets resolved in
/usr/include/x86_64-linux-gnu/SDL2. Due to this being included
from a compiler default system include path
(/usr/include/x86_64-linux-gnu), no warnings about the header
was printed, even though that one also produced the same kind
of conflicting redefinitions. (We could also avoid the same issue
by attempting to include <SDL2/SDL.h> instead of <SDL.h>,
avoiding the use of the build system provided include directory,
resolving that from /usr/include, and having the compiler consider
it a system header.)
The sdl2-compat package in Debian doesn't redirect that header
in the same way, but includes SDL_config_unix.h in the same
directory in /usr/include/SDL2. Due to this being included
from a user specified -I (as long as it is included as <SDL.h>,
not <SDL2/SDL.h>), it's considered a user header, and warnings
are printed for it.
It seems like SDL 3 no longer exposes their config.h headers as
part of the installed headers.
The conflict between SDL 2's config.h's HAVE_GETAUXVAL and
our stems from the fact that we only try to detect GETAUXVAL
on architectures where we want to use it (arm/aarch64, loongarch,
ppc or riscv). On x86, where we don't need it, we don't try
to detect it, and set "#define HAVE_GETAUXVAL 0" in our
config.h.
To avoid warnings due to the conflict, we can declare the
SDL 2 dependency with the argument "include_type: 'system'",
which should silence any warnings in the SDL headers. This
Meson feature is available since Meson 0.52.0 (and we currently
require Meson 0.54.0).
An alternative way to avoid the redefinition conflict would be
to always try to detect getauxval on all architectures, to make
our config.h agree with SDL 2's config headers.
A third (and much more hacky way) around the conflict would be
to avoid the public SDL headers including the SDL_config header
by defining "SDL_config_h_" before including SDL.h. Doing this
also requires manually including a couple more standard headers
before SDL.h (stdint.h, stdio.h, stddef.h).
Merges the 3 threading parameters into a single `--threads=` argument.
Frame threading can still be controlled via the `--framedelay=` argument.
Internally, the threading model is now a global thread/task pool design.
Co-authored-by: Ronald S. Bultje <rsbultje@gmail.com>
Neither --buildtype=plain nor --buildtype=debug set -ffast-math, so
llround() is kept as a function call and isn’t optimised out into
cvttsd2siq (on amd64), thus requiring the math lib to be linked.
Note that even with -ffast-math, it isn’t guaranteed that a call to
llround() will always be omitted (I have reproduced this on PowerPC), so
this fix is correct even if we ever decide to enable -ffast-math in
other build types.
The current playback loop triggers a repaint on any single event,
including spammy events such as SDL_MOUSEMOTION.
Fix this by only repainting on SDL_WINDOWEVENT_EXPOSED, which is defined
as the event sent when the window was damaged and needs to be repainted,
as well as on new frames.
Fixes https://code.videolan.org/videolan/dav1d/-/issues/356
Upstream libplacebo added support for dav1d integration directly,
allowing us to vastly simplify all of this code. In order to take
advantage of new optimizations, I had to allow update_frame to unref the
Dav1dPicture. (This is fine, since double unref is a no-op)
In addition, some of the functions we use were deprecated in recent
libplacebo versions, so since we're taking a new dependency we might as
well fix the deprecation warnings.
These functions are not thread-safe on GL, because they are not called
from the thread holding the GL context. Work around this by simply
disabling it.
Not very optimal, but better than crashing.
This one correctly sets the subsampling mode based on whether or not the
plane is actually subsampled, and also infers PL_CHROMA_UNKNOWN as
PL_CHROMA_TOP_LEFT in such cases.
libplacebo v66 got helper functions that make preserving the aspect
ratio in this case trivial. But we still need to make sure to clear the
FBO to black if the image doesn't cover it fully.
Returning out of this function when pl_render_image() fails is the wrong
thing to do, since that leaves the swapchain frame acquired but never
submitted. Instead, just clear the target FBO to blank red (to make it
clear that something went wrong) and continue on with presentation.
Annoying minor differences in this struct layout mean we can't just
memcpy the entire thing. Oh well.
Note: technically, PL_API_VER 33 added this API, but PL_API_VER 63 is
the minimum version of libplacebo that doesn't have glaring bugs when
generating chroma grain, so we require that as a minimum instead.
(I tested this version on some 4:2:2 and 4:2:0, 8-bit and 10-bit grain
samples I had lying around and made sure the output was identical up to
differences in rounding / dithering.)
Generalize the code to set the right pl_image metadata based on the
values signaled in the Dav1dPictureParameters / Dav1dSequenceHeader.
Some values are not mapped, in which case stdout will be spammed.
Whatever. Hopefully somebody sees that error spam and opens a bug report
for libplacebo to implement it.
Having the pl_image generation live in upload_planes() rather than
render() will make it easier to set the correct pl_image metadata based
on the Dav1dPicture headers moving forwards. Rename the function to make
more sense, semantically.
Reduce some code duplication by turning per-plane fields into arrays
wherever appropriate.
As an aside, also apply the correct chroma location rather than
hard-coding it as PL_CHROMA_LEFT.
This is turned into a const array in upstream libplacebo, which
generates warnings due to the implicit cast. Rewrite the code to have
the mutable array live inside a separate variable `extensions` and only
set `iparams.extensions` to this, rather than directly manipulating it.
../examples/dav1dplay.c:1030:5: warning: implicit declaration of function 'init_demuxers' is invalid in C99 [-Wimplicit-function-declaration]
init_demuxers();
^
/usr/bin/ld.bfd: examples/c590b3c@@dav1dplay@exe/dav1dplay.c.o: in function `decoder_thread_main':
dav1dplay.c:(.text+0x1243): undefined reference to `init_demuxers'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
Right now this just allocates a new buffer for every frame, uses it,
then discards it immediately. This is not optimal, either dav1d should
start reusing buffers internally or we need to pool them in dav1dplay.
As it stands, this is not really a performance gain. I'll have to
investigate why, but my suspicion is that seeing any gains might require
reusing buffers somewhere.
Note: Thrashing buffers is not as bad as it seems, initially. Not only
does libplacebo pool and reuse GPU memory and buffer state objects
internally, but this also absolves us from having to do any manual
polling to figure out when the buffer is reusable again. Creating, using
and immediately destroying buffers actually isn't as bad an approach as
it might otherwise seem.
It's entirely possible that this is only bad because of lock contention.
As said, I'll have to investigate further...
Only meaningful with libplacebo. The defaults are higher quality than
SDL so it's an unfair comparison and definitely too much for slow iGPUs
at 4K res. Make the defaults fast/dumb processing only, and guard the
debanding/dithering/upscaling/etc. behind a new --highquality flag.
When compiling in release mode, instead of just deleting assertions,
use them to give hints to the compiler. This allows for slightly
better code generation in some cases.
Martin Storsjö
Cameron Cawley
Michael Bradshaw
Henrik Gramner
Niklas Haas
Victorien Le Couviour--TuffetandRonald S. Bultje
James Almer
Emmanuel Gil Peyrot
Niklas Haas
Marvin Scholz
Konstantin Pavlov
Jan Beich