kdePackages.qtmultimedia: patch for pipewire and other

[Bot-wxt1221]

I haven't darwin machine so I won't do change on it.

Expected to close: #432137

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

Review dismissed automatically

[SuperSandro2000]

@K900 can you take a look? Not my area tbh.

[K900]

I still don't think we need the ffmpeg stuff at all, we're using the gstreamer backend as recommended upstream. I'm not sure what Pipewire is used for here.

[Bot-wxt1221]

@K900 But is it what we should care. Upstream use it, and we use it.

I will split ffmpeg into another PR.

[K900]

That's... not how any of this works, no.

[Bot-wxt1221]

@K900 What do you mean

[K900]

I mean that we don't add dependencies just because upstream lists them, we need to understand what we're doing and why.

[Bot-wxt1221]

@K900 #432137 some packages did use pipewire. It generate errors. And pipewire is currently in buildInputs

[K900]

I think that issue is conflating a whole bunch of unrelated errors due to unrelated warnings.

[K900]

As far as I can tell, all of the libva/libssl stuff is only used by the ffmpeg backend, which we, again, don't use and don't need.

[puetzk]

I'm confused by this claim that we (I assume you mean nixpkgs) don't use the ffmpeg backend - it became the default in Qt 6.5 (
https://doc.qt.io/qt-6.5/qtmultimedia-index.html#ffmpeg-as-the-default-backend), nixpkgs started building it in #271922, and that's what seems to be in use (e.g. if I open a video file in gwenview, or parole, or play music in elisa, etc, /nix/store/0d97dxdvc0k0b1qgzar9njlmg0ijxhcw-qtmultimedia-6.10.1/lib/qt-6/plugins/multimedia/libffmpegmediaplugin.so is the plugin I see loaded. And I don't think I've done anything special to force this...

To quote from the more current docs

https://doc.qt.io/qt-6/qtmultimedia-index.html#native-backends
The GStreamer backend is only available on Linux, and is only recommended for embedded applications

And, other than webassembly continuing to use browser-provided media acceleration, the other non-ffmpeg plugins all seem to be heading toward deprecation

• MediaCodec on Android is deprecated as of Qt 6.8 and will be removed in the next major release
• The Windows media backend built on top of Windows Media Foundation is deprecated as of Qt 6.10 and will be removed in the next major release.

Now, it is true that nixpkgs is still also building libgstreamermediaplugin.so too, but I don't think anything much is using it...

[K900]

Ugh, sorry, my wires got crossed, I was thinking about Phonon here. The ffmpeg backend for qtmultimedia is fine.

[puetzk]

At least part of what's going wrong here seems to be that this ENABLE_DYNAMIC_RESOLVE_VAAPI_SYMBOLS=0 doesn't exist after Qt 6.9 (specifically after qt/qtmultimedia@d0a1eaa)

At least at that time, you decided it was OK to link to libva.so.2 directly (which is what that define accomplished, it made the qtmultimediaplugin link to libva, which then (at least per the discussion at #271922 (comment)) handled loading the x11, drm, etc backends in its own (impure) fashion)

[puetzk]

But without that mechanism, what was previously happening to libva is back, and now also happening to libpipewire - Qt has omitted a real NEEDED in favor of qpipewire_symbolloader.cpp using dlopen (via QLibrary), so it doesn't end up with a real ld.so dependency that would capture the absolute path, and nix then doesn't get the a complete closure of runtime dependencies.

Now, in some sense this is all working as Qt intended - strictly speaking, this is an optional dependency and most QtMutimedia functionality can work even if libpipewire isn't found. But they're expecting that if you install libpipewire, qtmultimedia can find it. And that kind of impure "use it if it happens to be there" almost never works on nix, where nothing is in the LD_LIBRARY_PATH just because it's in the store.

[puetzk]

I'm not sure what Pipewire is used for here.

pipewire or pulseaudio are the two supported linux implemtations for a QAudioSink. There's also an ALSA one but it's simultaneously experimental and deprecated (i.e. it doesn't work great and nobody intends to fix that). There's also QPipewireAudioSource that can be used for screen captures with sound.

[puetzk]

So basically, the problem here is being caused by the use of QLibrary/dlopen to make the references to some of these external dependencies optional at runtime, colliding with the way doesn't just dump everything in an impure /usr/lib.

seaching for the BEGIN_INIT_FUNCS macro that declares these symbol-resolver intercepts, there are 5 of them:

• src/multimedia/pipewire/qpipewire_symbolloader.cpp:18
  BEGIN_INIT_FUNCS("pipewire-" PW_API_VERSION, "0")
• src/plugins/multimedia/ffmpeg/symbolstubs/qffmpegsymbols-va.cpp:23
  BEGIN_INIT_FUNCS("va", VA_NEEDED_SOVERSION, loggingName)
• src/plugins/multimedia/ffmpeg/symbolstubs/qffmpegsymbols-va-x11.cpp:10
  BEGIN_INIT_FUNCS("va-x11", VA_X11_NEEDED_SOVERSION)
• src/plugins/multimedia/ffmpeg/symbolstubs/qffmpegsymbols-va-drm.cpp:10
  BEGIN_INIT_FUNCS("va-drm", VA_DRM_NEEDED_SOVERSION)
• src/plugins/multimedia/ffmpeg/symbolstubs/qffmpegsymbols-ssl.cpp:63
  BEGIN_INIT_FUNCS("ssl", loadLib)

I don't think we actually care about the ffmpeg/symbolstubs/* ones; those are for the scenario described in FFmpeg stub libraries on Linux and Android, where a binary distribution of Qt has bundled its own patchelf'ed build of ffmpeg that refers to e.g. libQt6FFmpegStub-va.so.X instead of libva.so.X. This lets QtMultimedia be a man-in-the-middle and either delegate back to runtimes (impurely loaded with dlopen) if they are available, or to stubs that make it a runtime (rather than launch-time) error if not. But that way it can ship an ffmpeg with those features compiled in, but use them only when installed, and use other parts of those ffmpeg binaries even if libssl, libva, etc are missing.

But none of that is applicable to nix, where all dependencies are hard and pure; if compiled against the ffmpeg derivation, then /nix/store/vchl01kvlgrjmxy0acrhzw7n7dwn4hsz-qtmultimedia-6.10.1/lib/qt-6/plugins/multimedia/libffmpegmediaplugin.so has a NEEDED for /nix/store/p3h2vdzm29v8v5z3vbf56x8v24d9ry30-ffmpeg-8.0-lib/lib/libavcodec.so.62 has a NEEDED for /nix/store/pczxxiw49zz8ybi7gchk1i1f7aadgv67-libva-2.22.0/lib/libva.so.2, and none of this ever refers to the those ibQt6FFmpegStub-*.so shims. It doesn't seem like they end up included in the nix qtmultimedia outputs. Certainly the nix store's build of libavcodec.so.62.11.100 isn't going to contain any references that would try to use them, it'll reference other real derivations for its dependencies. So we don't really need to care about making the dlopens in src/plugins/multimedia/ffmpeg/symbolstubs work, they should (and seem) to be dead-stripped during linking, and will in any case never get called.

However, that isn't the case for pipewire. Here it really is the case that libQt6Multimedia.so contains code that will try to dlopen("libpipewire-0.3.so") at runtime. But, since didn't actually get -lpipewire, it didn't get those folders included in its RUNPATH. patchelf --add-rpath ${ lib.makeLibraryPath [ pipewire ] } seems like an OK solution to that one...

[puetzk]

What in qtmultimedia would use libsysprof-capture at build time?

[Bot-wxt1221]

I found it error in old log from pkg-config

[K900]

Once again, getting rid of every possible build warning is explicitly not a goal.