qt6.qtmultimedia: Enable ffmpeg/VAAPI backend#271922
Conversation
github-actions
bot
added
6.topic: nixos
There was a problem hiding this comment.
Another possible approach here would presumably be to somehow set an rpath, but runtimeDependencies = [ libva.out ] didn't work. I am not very familiar with this stuff, but found that pattern in e.g.
nixpkgs/pkgs/applications/networking/browsers/firefox-bin/default.nix
Lines 90 to 92 in c2273e1
I presume it worked there but not here because firefox's derivation owns the top-level executable, but qtmultimedia only has libraries/plugins and DT_RUNPATH isn't transitive.
Either solution would cause qtmultimedia-6.6.1/lib/qt-6/plugins/multimedia/libffmpegmediaplugin.so to menton libva's store path, and thus make it part of the closure. And in fact we had it in the closure already anyway (via part of ffmpeg-6.0-lib). And squashing this kind of "use if it it happens to be found" variability is a big part of nix's purpose.
So it seems simplest to just to tell Qt we would prefer that it simply link QFFmpegMediaPlugin to LIBRARIES VAAPI::VAAPI
resulting in an ordinary DT_NEEDED.
But I'm still relatively new to nix, and even more to nixpkgs, so I'd welcome any reviewer feedback on what's preferred in cases where upstream uses dlopen as a way to have optional features...
There was a problem hiding this comment.
rebased to fix the merge conflict vs #269475 (in release notes) - which, coincidentally, may be somewhat related to the question of how we would like QtMultimedia (and ffmpeg itself) to find hardware-acceleration dependencies like CUDA/VAAPI (and possibly libvdpau in the future, though QtMultimedia currently has AV_HWDEVICE_TYPE_VDPAU disabled.
There was a problem hiding this comment.
but
runtimeDependencies = [ libva.out ]didn't work.
By default this is not used in stdenv.
Is this just about which libva is being used or the graphics driver? If it is just the former I don't know why we shouldn't hardcode it.
There was a problem hiding this comment.
libva loads backends dynamically (and impurely), so this is totally fine.
There was a problem hiding this comment.
The warnings I mentioned in this commit are about about libffmpegmediaplugin.so loading libva.so with dlopen: see https://github.com/qt/qtmultimedia/blob/v6.6.1/src/plugins/multimedia/ffmpeg/qffmpegvaapisymbols.cpp#L22-L38
But the Qt CMake logic gives you a choice (via DYNAMIC_RESOLVE_VAAPI_SYMBOLS) to actually link to it instead (which is what I chose to do):
https://github.com/qt/qtmultimedia/blob/v6.6.1/cmake/FindFFmpeg.cmake#L197-L214
https://github.com/qt/qtmultimedia/blob/v6.6.1/src/plugins/multimedia/ffmpeg/CMakeLists.txt#L111-L121
Which seemed fine since libva does the backends separately anyhow (and because nix's ffmpeg already just linked it), but I appreciate the confirmation, since I'm still learning the nix conventions...
There was a problem hiding this comment.
I'm also not sure whether to ask that this be backported to 23.11 - I'd personally like it to be, and it kind of seems like it should given that this is upstream's default and they are pretty negative on continued support for gstreamer:
https://doc.qt.io/qt-6.5/qtmultimedia-index.html#backend-support
Furthermore, even some major issues with the gstreamer backend (on Linux) won't be fixed since gstreamer is difficult to debug and is further complicated as it is dependent on Linux distributions.
But it does affect the set of supported codecs (though mostly for the better...).
Opinions welcome on that too - for now I only added to 24.05 release notes "Notable changes"
There was a problem hiding this comment.
I suppose another possibility would be to set it up as a multiple-output derivation (so qt6.qtmultimedia.ffmpeg and qt6.qtmultimedia.gstreamer could be separated and not have the closure include both when only one or the other will be used). Then 23.11 and 24.05 could offer both choices, but with a different "default" (which one is propagated a build input on qt6.qtmultimedia).
But I'm not familiar with doing this, nor do I see anything similar being done in the other Qt packages. E.g. qtbase could have split the xcb vs wayland QPA plugins in a similar fashion, since it's unlikely anybody really wants both. But I didn't find any pattern to imitate...
There was a problem hiding this comment.
I don't think we need to duplicate this and since qt6 will only start to take off with plasma6 which will not be backported, I don't think we need to backport this either.
There was a problem hiding this comment.
easy enough to use an override in the case I cared about. If there isn't actually much moving toward Qt6 until 24.05 that's a sane reason to leave well enough alone.
This was Tech Preview in Qt 6.4, released in 6.5
puetzk
force-pushed
the
qt6-qtmultimedia-ffmpeg
branch
from
035059d to
6cf1504
Compare
|
Overall change seems good, but may need to retarget to staging depending on rebuild count impact? |
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
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
puetzk
force-pushed
the
qt6-qtmultimedia-ffmpeg
branch
from
6cf1504 to
7e88653
Compare
it hasn't finished yet, but from nixpkgs-review it isn't insanely big:
Happy to retarget if that's preferred |
|
One failure from nixpkgs-review (so far), on olive-editor-unstable
This seems unrelated and already known (#260603 (comment) saw it on master last week), and has its own PR #271909 going already. |
|
nixpkgs-review completed (no failures except olive-editor) |
puetzk
changed the title
ofborg
bot
added
10.rebuild-darwin: 11-100
3 participants
Description of changes
Enable new QtMultimedia plugins to match upstream recommendations/defaults for Qt6.6
https://doc.qt.io/qt-6.5/qtquick3d-audio-qmlmodule.html
https://doc.qt.io/qt-6.5/qtmultimedia-index.html#ffmpeg-as-the-default-backend
See also #194167 (closed unmerged) which had started to make similar changes back in Qt 6.4; I presume it was rejected/abandoned because at that point these new backends were still technology previews and not enabled by default in the upstream releases either. Now they are the recommended defaults.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)--
Add a 👍 reaction to pull requests you find important.