Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. 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 Eli Schwartz (eschwartz) - Wednesday, 10 July 2019, 20:18 GMT
Task Type Feature Request
Category Packages: Extra
Status Assigned
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 0%
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

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.

Loading...