Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#62976 - [pipewire] reduce FFmpeg plugin and gstreamer plugin to optdepends

Attached to Project: Arch Linux
Opened by A. Bosch (progandy) - Saturday, 22 June 2019, 14:41 GMT
Last edited by David Runge (dvzrv) - Tuesday, 08 February 2022, 17:52 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Jan Alexander Steffens (heftig)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
Pipewire includes a plugin to embed it in gstreamer pipelines.
There is also a pipewire plugin to include ffmpeg in pipewire pipelines.

These two plugins result in a large dependency tree including many video and audio codecs in addition to gstreamer and ffmpeg.

I propose to split these two plugins into separate packages and declare them as optdepends and reduce the dependencies of a basic pipewire installation similar to gstreamer and gst-plugins-...

For example Chromium is compiled with pipewire support and at least normal functionality doesn't require those plugins. Everything functions normally after deleting the plugin objects. I haven't tested screen sharing, but installing an optional dependency for that should be acceptable if it proves to be necessary.

Additional info:
* package version(s)
pipewire 0.2.6+1+g37613b67-1
chromium 75.0.3770.100-1

* plugin paths:
/usr/lib/gstreamer-1.0/libgstpipewire.so
/usr/lib/spa/ffmpeg/libspa-ffmpeg.so
This task depends upon

Closed by  David Runge (dvzrv)
Tuesday, 08 February 2022, 17:52 GMT
Reason for closing:  Fixed
Additional comments about closing:  Pipewire optdepends on gst-plugin-pipewire. The ffmpeg based plugin has been dropped upstream.
Comment by Eli Schwartz (eschwartz) - Sunday, 23 June 2019, 03:13 GMT
Luckily no one will ever notice, because Chromium already has a hard dependency on ffmpeg.

Also literally the whole point of pipewire is to provide "multimedia pipelines", and if you have programs that make use of "multimedia pipelines", then they will generally tend to already be using ffmeg, gstreamer, or both.

Random question: does pipewire still run correctly if you force remove gstreamer or ffmpeg and use it with some program that doesn't already link to the thing you just removed? You say you tested it after deleting the plugin objects, but does it work *before* you delete the plugin objects?
Comment by A. Bosch (progandy) - Sunday, 23 June 2019, 12:36 GMT
There is also the unneeded gstreamer dependency for Chromium, that adds ~60MiB on top of ffmpeg.

Yes, gstreamer is meant to provide "multimedia pipelines", but I see it more as the plumbing that doesn't have explicit dependencies on codecs. In practice, it probably won't make a noticable difference since it is very common to install at least one package that requires ffmpeg and another with gstreamer.


The gstreamer plugin is loaded by gstreamer, so having the file around doesn't matter if gstreamer is not installed.

As far as I can see, a missing spa-ffmpeg plugin will just result in those pipeline elements not being available. It looks like pipewire handles a missing plugin and an unloadable plugin the same. It just tries dlopen when it is asked to load a plugin.


The video-play example from the pipewire repository works without gstreamer and ffmpeg and displays my webcam video in an SDL window:

$ CUTF p -Q ffmpeg gstreamer
error: package 'ffmpeg' was not found
error: package 'gstreamer' was not found
$ CUTF ls -l /usr/lib/gstreamer-1.0/libgstpipewire.so /usr/lib/spa/ffmpeg/libspa-ffmpeg.so
-rwxr-xr-x 1 root root 120648 Jun 15 03:44 /usr/lib/gstreamer-1.0/libgstpipewire.so
-rwxr-xr-x 1 root root 54960 Jun 15 03:44 /usr/lib/spa/ffmpeg/libspa-ffmpeg.so
$ pipewire
[E][v4l2-utils.c:91 spa_v4l2_open()] v4l2: /dev/video1 is no video capture device
[E][module-protocol-native.c:336 client_new()] no peersec: Protocol not available
[E][v4l2-utils.c:91 spa_v4l2_open()] v4l2: /dev/video1 is no video capture device

Second terminal:
$ CUTF /tmp/pw/video-play
remote state: "connecting"
remote state: "connected"
remote state: "unconnected"
remote state: "connecting"
remote state: "connected"
stream state: "connecting"
stream state: "configure"
stream state: "ready"
stream state: "paused"
stream state: "streaming"
stream state: "unconnected"
remote state: "unconnected"

So to answer the random question, yes it does run. A split package is completely unnecessary, marking those as optdepends would be plenty.
Comment by Eric Wang (enihcam) - Tuesday, 09 July 2019, 23:53 GMT
A split package is necessary because it avoids the handling logic in run-time. Postpone the plugin check to run-time means user test is needed, and you might need to worry about the regression or side-effects.

update:
'pipewire-gstfree' is available for AUR users already. Please split the package in the official repo so users don't need to compile by themselves.
Comment by Eli Schwartz (eschwartz) - Wednesday, 10 July 2019, 20:18 GMT
  • Field changed: Summary (PipeWire: Create split packages for FFmpeg plugin and gstreamer plugin → [pipewire] reduce FFmpeg plugin and gstreamer plugin to optdepends)
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Architecture (x86_64 → All)
  • Task assigned to Jan Alexander Steffens (heftig), Jan de Groot (JGC)
I suppose considering pipewire to be the plugin framework and assuming users will install the optdepends for the backends they wish to use, seems like a reasonable approach. Given that pipewire is well-behaved w.r.t. dynamically detecting which plugins work, this seems to be fairly harmless.

Let's see what the maintainers think.
Comment by tinywrkb (tinywrkb) - Monday, 16 November 2020, 22:03 GMT
Pipewire's developer also maintains the Fedora packaging for Pipewire which splits the GStreamer module to a separate package, and if I understand correctly it's not required directly or indirectly by the Pipewire package. Can any else confirm this.

Also, for some reason, it doesn't look like Fedora is building the FFMpeg module.

Source: https://src.fedoraproject.org/rpms/pipewire/blob/master/f/pipewire.spec

Rawhide's pipewire RPM: https://fedora.pkgs.org/rawhide/fedora-x86_64/pipewire-0.3.15-2.fc34.x86_64.rpm.html

Rawhide's pipewire-gstreamer RPM: https://fedora.pkgs.org/rawhide/fedora-x86_64/pipewire-gstreamer-0.3.15-2.fc34.x86_64.rpm.html
Comment by Jan de Groot (JGC) - Wednesday, 18 November 2020, 09:13 GMT
ffmpeg was dropped in 0.2.7-2 and wasn't added back after that, so Arch follows Fedora in not packaging the ffmpeg module.
As for GStreamer, we're talking about a GStreamer plugin that is not utilized by Pipewire itself, but allows GStreamer to interface with Pipewire.

Splitting involves identifying the packages that require the plugin for correct operation. Moving to optdepends is the easiest here, but probably not the prefered solution.
Comment by tinywrkb (tinywrkb) - Wednesday, 18 November 2020, 18:29 GMT
@JGC what about moving the module into pipewire-gstreamer but adding pipewire-gstreamer to the depends array of pipewire in the package function?
This way users who want to avoid gst could install a dummy package instead of having to rebuild pipewire with gst disabled.

edit: ahh... nvm, my brain cells stopped working, that was a silly suggestion.

Loading...