QtMultimedia 6.6.0 would select dynamic VAAPI on linux, then warns
during build (even though it chose this on purpose):
> QT_FEATURE_vaapi is found but ffmpeg doesn't include vaapi,
> however dynamic symbols resolve is possible
The nuisance warning was fixed for 6.7 and backported to 6.6.1:
https://codereview.qt-project.org/c/qt/qtmultimedia/+/517333
However, tracing it helped me figure out why vaapi actually wasn't
working: nix doesn't end up with an rpath such that dlopen("va")
can actually find libva.so in the nix store, thus failing at runtime:
> qt.multimedia.plugin: loading backend "ffmpeg"
> qt.core.library: "/nix/store/i9fkjks6dfjj1p9qvj5633sxbrf5rbd8-qtmultimedia-6.6.1/lib/qt-6/plugins/multimedia/libffmpegmediaplugin.so" loaded library
> qt.multimedia.ffmpeg.libsymbolsresolver: Start VAAPI symbols resolving: 39 symbols
> qt.core.library: "va" cannot load: Cannot load library va: (va: cannot open shared object file: No such file or directory)
> qt.multimedia.ffmpeg.libsymbolsresolver: Couldn't load VAAPI library
This is now the default recommendation upstream for linux platforms
> https://doc.qt.io/qt-6.6/qtmultimedia-index.html#ffmpeg-as-the-default-backend
> In this release the FFmpeg framework is set as the default backend on
> Windows, macOS, Android, and Linux except Yocto distribution.
> The version shipped with Qt binary packages is FFmpeg 6.0
> and is tested by the maintainers.
libXrandr is required to compile support QT_WINDOW_CAPTURE_BACKEND=x11
Specify a deployment target of 10.13 to avoid errors due to clang’s
having a hard-coded check for 10.13 when using them (even though it
implements them with `posix_memalign`, which is available on earlier
versions of macOS).
QtWebEngine tries to build with clang 14, which links libc++ 14, but the
top-level libc++ on Dariwn is libc++ 16. This results in a crash during
the build, which is fixed by building with the default stdenv.
A few qt6 modules require python. We need to override with the
appropriate python version in order to use qt6 with non-default python
packages (like python311).
Nix builds of QTWebEngine doesn't support sound output via Pulse, only
through ALSA, unless sandboxing is disabled and LD_LIBRARY_PATH
contains a reference to the Pulse libraries.
By default, Chromium won't link to PulseAudio, but dlopens it in
run-time. It is tricky to make this work because of the nontrivial
sandbox configuration. Nix builds of Chromium already link against
Pulse directly, so it makes sense to copy this behavior in
QTWebEngine.
