Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 825082 - media-plugins/gst-plugins-meta: Please add pipewire use-flag
Summary: media-plugins/gst-plugins-meta: Please add pipewire use-flag
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: GStreamer package maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-20 03:26 UTC by tastytea
Modified: 2022-05-25 20:35 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tastytea 2021-11-20 03:26:16 UTC
In order to make pipewire work with gstreamer, it has to be installed with the gstreamer use-flag. So my idea is to add a pipewire use-flag to media-plugins/gst-plugins-meta and depend on media-video/pipewire[gstreamer] if it is set.

Reproducible: Didn't try

Steps to Reproduce:
A user of net-im/nheko::guru and pipewire has reported that their audio did not work. After installing media-video/pipewire with the gstreamer use-flag it worked.
Comment 1 Niklāvs Koļesņikovs 2021-12-21 15:17:58 UTC
Since media-plugins/gst-plugins-meta is a meta package, that's possible but I'm not sure why that would be needed - if someone wants to use gstreamer they should already have USE=gstreamer in their make.conf.

Furthermore I would like to know if media-plugins/gst-plugins-pulse really did not work with pipewire-pulse daemon as is. If gstreamer is out of the box broken with PipeWire, that's an entirely different thing and probably requires more than a mere pipewire IUSE on it (since a user who lacks USE=gstraemer may as well not have USE=pipewire either).
Comment 2 tastytea 2021-12-21 17:53:37 UTC
I'm not very familiar with PipeWire and GStreamer. But it looks like it is possible to use PipeWire without GStreamer? media-video/pipewire has IUSE="gstreamer". So somebody could use PipeWire but not GStreamer and then install a program which needs GStreamer and audio wouldn't work because media-video/pipewire was compiled without USE="gstreamer". That seems to have happened.

Why would a PipeWire-user have media-plugins/gst-plugins-pulse installed? The user had USE="pipewire -pulseaudio" and not enabled gstreamer globally.
Comment 3 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-12-21 18:00:07 UTC
(In reply to tastytea from comment #2)
> I'm not very familiar with PipeWire and GStreamer. But it looks like it is
> possible to use PipeWire without GStreamer? media-video/pipewire has
> IUSE="gstreamer". So somebody could use PipeWire but not GStreamer and then
> install a program which needs GStreamer and audio wouldn't work because
> media-video/pipewire was compiled without USE="gstreamer". That seems to
> have happened.
> 
> Why would a PipeWire-user have media-plugins/gst-plugins-pulse installed?
> The user had USE="pipewire -pulseaudio" and not enabled gstreamer globally.

Wouldn't they also lack the meta in that case anyway? Or did they have it installed?
Comment 4 tastytea 2021-12-21 18:10:48 UTC
(In reply to Sam James from comment #3)
> (In reply to tastytea from comment #2)
> > The user had USE="pipewire -pulseaudio" and not enabled gstreamer globally.
> 
> Wouldn't they also lack the meta in that case anyway? Or did they have it
> installed?

They had media-plugins/gst-plugins-meta installed because the program using gstreamer (net-im/nheko::guru) depends on it. I don't know if every program using gstreamer necessarily depends on meta, but a lot of them do I think.
Comment 5 Niklāvs Koļesņikovs 2021-12-21 20:13:48 UTC
This is sort of a grey area. IMO, if a person decides to do disable common desktop components such as PulseAudio via USE=-pulseaudio in make.conf, they then take it up on themselves to ensure their resulting deployment still works well enough for them. And in this case it turned out they manually had to flip on another use flag somewhere seemingly unrelated.

This is particularly true, if instead of a barest of bones system that might have nothing in common with a modern desktop environment, they then proceed to use a fairly large FreeDesktop.org component such as GStreamer which is bound to depend and meant to be used with other FDO projects such as D-Bus or PulseAudio. PipeWire is another FDO related project, by the way.

Also I checked the USE description of all pipewire USE flags available and currently media-libs/libsdl2 is the only one which promises any audio support at all (which is not enabled by default even if enabled at build time, from what I know). Meaning that it's actually wrong to expect USE="pipewire -pulseaudio" to magically switch audio from PulseAudio to PipeWire backend (since the latter almost never exists, and, should it exist, is probably a config/environment variable opt-in). This makes this bug also based on incorrect assumptions.

If the out of the box experience with the desktop profile was broken, that would be compelling reason to fix this but, if it's only people who selectively flip on FDO related USE flags, then, IMO, it's exactly in accordance to the Gentoo deal they have: you get to build your own custom and unique distro but it's on you to get things right. And having to adjust USE flags on another FDO package is definitely something that may be included in your Gentoo experience package, should you decide to go full custom instead of using a desktop profile and (mostly) going with the flow.
Comment 6 Niklāvs Koļesņikovs 2022-05-25 15:41:37 UTC
Having re-read everything, I think the actual core issue is that currently Gentoo's GStreamer packaging does not appear to have a way to indicate that GStreamer consumer wants an audio backend that will work. Or is the assumption that one would always be available? In that case gst-plugins-meta probably needs to enforce that at least one of the backends will be available.

Alternatively it could be concluded that the system about which this bug was filed is so misconfigured (apparently effectively USE="-alsa -pulseaudio") that it's out of Gentoo support and this bug can be closed as not a bug, since disabling all audio backends and then expecting the impossible from USE=pipewire is just not how things work.
Comment 7 tastytea 2022-05-25 17:05:05 UTC
(In reply to Niklāvs Koļesņikovs from comment #6)

I can agree with both arguments. Since all desktop profiles set at least 
USE="alsa" and the PipeWire wiki page explicitly warns[1] against removing 
USE="pulseaudio", it is certainly a misconfiguration.

On the other hand, having gst-plugins-meta enforce a working backend would be 
nice, and since it has USE-flags for alsa, pulseaudio and even oss it would 
seem logical to add one for pipewire too.

[1] <https://wiki.gentoo.org/wiki/PipeWire#Replacing_PulseAudio>
Comment 8 Niklāvs Koļesņikovs 2022-05-25 20:35:23 UTC
While there's definitely been talk of having USE=pipewire for audio and USE=screencast for the screen capture transport, I don't think anyone ever agreed on formalizing anything which is why both flags are package specific and sometimes contradictory in use (e.g. weston uses pipewire IUSE for what should be screencast). Meaning it is currently wrong to expect pipewire to provide exactly audio or even audio backend for the package which has it.

Furthermore, while I'm not sure there's any official guidelines on this and developer opinion varies, in general Gentoo does not go out of its way to cater to users who intentionally misconfigure their systems beyond their ability to keep them working. The only and probably still informal rule is to not go out of your way to break such setups just out of spite or malice.