Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PipeWire and fixing the Linux Video Capture stack

blogs.gnome.org

Post reply on HN
Print view View original

21–30 of 38 posts

Re: PipeWire and fixing the Linux Video Capture stack

#21

Post by minetest2048 »

pimeys wrote: post #10

I really wish Zoom could start using PipeWire for their screen sharing and video as soon as possible. Currently their desktop app gives a very interesting error if trying to share the screen from Wayland/sway. There is no need to only support Gnome on Ubuntu et.al. with PipeWire. The only way to use Zoom from my point of view is through their web app. And every time I start a meeting from their web interface, they're…

Adding to this I also wish Zoom to use native Pipewire for desktop audio capture, currently Zoom desktop audio sharing doesn't work when pulseaudio is replaced by pipewire

Re: PipeWire and fixing the Linux Video Capture stack

#22

Post by patrickthebold »

pimeys wrote: post #10

I really wish Zoom could start using PipeWire for their screen sharing and video as soon as possible. Currently their desktop app gives a very interesting error if trying to share the screen from Wayland/sway. There is no need to only support Gnome on Ubuntu et.al. with PipeWire. The only way to use Zoom from my point of view is through their web app. And every time I start a meeting from their web interface, they're…

Would obs be helpful here? I would think you could tell zoom about an obs virtual camera and use obs with pipewire for the capture.

Re: PipeWire and fixing the Linux Video Capture stack

#23

Post by ubercow13 »

hulitu wrote: post #12
mjevans wrote: post #6

Earlier quoted context omitted.

A reboot is often required to integrate the session changes. https://wiki.archlinux.org/title/PipeWire Your session environment might also need to be aware of how to interact with PipeWire, which by default is via pulsaudio compatibility interfaces. Required (practically, probably pulled in with just pipewire): pipewire pipewire-media-session pipewire-pulse Recommended: pipewire-alsa pipewire-jack lib32-pipewire lib3…

> "A reboot is often required to integrate the session changes." "To apply the changes you must restart your computer" It is just sad.

It's not necessary it's just easy to explain.

Re: PipeWire and fixing the Linux Video Capture stack

#24

Post by kzrdude »

alias_neo wrote: post #19
nyanpasu64 wrote: post #8

Earlier quoted context omitted.

Does `systemctl --user disable --now pulseaudio` help? Also you can use `enable --now` to enable and start at the same time.

Don't forget to mask pulseaudio, just disabling it isn't enough.

The difference seems to be:

disabled - the service is not started automatically

masked - the service can't be started at all, even explicitly requested by user or app

Re: PipeWire and fixing the Linux Video Capture stack

#25

Post by alias_neo »

kzrdude wrote: post #24
alias_neo wrote: post #19

Earlier quoted context omitted.

Don't forget to mask pulseaudio, just disabling it isn't enough.

The difference seems to be: disabled - the service is not started automatically masked - the service can't be started at all, even explicitly requested by user or app

On Ubuntu at least, I had to mask it otherwise pulseaudio was started again on reboot despite being disabled.

Re: PipeWire and fixing the Linux Video Capture stack

#26

Post by PaulDavisThe1st »

One clarification to TFA:

>And also we can have patchbay applications that supports video pipelines and not just audio, like Carla provides for Jack applications. To be clear this feature will not come for ‘free’ from Jack patchbays since Jack only does audio, but hopefully new PipeWire patchbays like Helvum can add video support.

There actually have been patches for JACK to enable it transport video just like it already handles audio & MIDI. We never accepted them into the mainstream.

The specific problem with video compared with audio is this: for audio, settling on 32 bit floating point as the canonical format for audio (and note, JACK did not prevent you from using other formats, even internally; people just didn't bother) was not even remotely controversial. Nothing is lost and much is gained via this choice.

For video, however, there are a plethora of possible format choices, each with their own distinct reasons for being, and often significant computational costs associated with conversion. This means that for video it's fairly problematic to define a single format for an entire workflow, which in turn means that figuring out when/where conversion between formats occurs is a significant task. For JACK, we decided not to try to do this, and left the system handling only audio & MIDI.

Re: PipeWire and fixing the Linux Video Capture stack

#27

Post by HMH »

> In fact in the first few releases of Fedora Workstation where we shipped PipeWire we solely enabled it as a tool to handle screen sharing for Wayland and Flatpaks.

PipeWire is truly a godsend for screen recording on Wayland, not very long ago, if at all, every desktop environment / compositor had their own home brewed protocol and developing anything related to screen recording on Wayland was a massive pain [1]. I still can not fathom how Wayland could even exist this long without any decent way to do screen recording and I also do not get why there is no official protocol or at least extension for this!

But thanks to PipeWire some first projects finally support screen capturing on Wayland. Both Firefox (via webrtc) [2] and OBS [3] directly interface with PipeWire. For my personal project Weylus [4] I opted for the gstreamer plugin as at the time the documentation for PipeWire itself was very lacking and I could not figure out how to get it to work. Fortunately gstreamer is better documented and it turned out to be rather easy to use. But it shows that all this is still in an early stage as I hit quite some bugs, probably the most egregious (maybe even somewhat funny) one is KDE's kwin_wayland crashing if you hover the cursor over any window close button while screen recording [5], sadly it doesn't seem to be fixed yet. For some more bugs I've hit, see [6].

Something I am a little worried about is that flatpak with their xdg-desktop-portal [7] is now responsible for the de facto standard how screen recording is negotiated on Wayland. I fear that this means if flatpak does not need a feature, even if it makes sense in another context, it probably won't ever be implemented. For example something I require for my project are proper window names and their position as well as size, but apparently this is nothing essential for flatpak and the issues I have opened have largely been ignored [8]. This is by no means meant as an accusation, just an observations that things are not all good.

[1]: https://github.com/H-M-H/Weylus/issues/3#issuecomment-652670...

[2]: https://webrtc.googlesource.com/src/+/refs/heads/main/module...

[3]: https://github.com/obsproject/obs-studio/blob/master/plugins...

[4]: https://github.com/H-M-H/Weylus

[5]: https://bugs.kde.org/show_bug.cgi?id=435042

[6]: https://github.com/H-M-H/Weylus/issues/3#issuecomment-808940...

[7]: https://github.com/flatpak/xdg-desktop-portal

[8]: https://github.com/flatpak/xdg-desktop-portal/issues/created...

Re: PipeWire and fixing the Linux Video Capture stack

#28

Post by Jasper_ »

hulitu wrote: post #12
mjevans wrote: post #6

Earlier quoted context omitted.

A reboot is often required to integrate the session changes. https://wiki.archlinux.org/title/PipeWire Your session environment might also need to be aware of how to interact with PipeWire, which by default is via pulsaudio compatibility interfaces. Required (practically, probably pulled in with just pipewire): pipewire pipewire-media-session pipewire-pulse Recommended: pipewire-alsa pipewire-jack lib32-pipewire lib3…

> "A reboot is often required to integrate the session changes." "To apply the changes you must restart your computer" It is just sad.

You've always had to basically reboot your computer for big system component changes to be applied, otherwise you'll have some applications running the old system, and some running the new system. Yes, you could close those applications, but that's practically every process in your session, and getting the order right is tricky.

Both PulseAudio and PipeWire work best when running the underlying kernel drivers in "exclusive" mode, which means only one sound server can be running at a time. In order to ensure that works correctly, you need to:

1. Close all applications

2. Shut down PulseAudio and prevent it from auto-restarting

3. Start up PipeWire, and then restart your desktop environment if you want any hope of the volume applet working (or figure out which of the processes to kill if your volume applet in another process)

4. Start up your applications again.

5. There might be some applications that have tried to play audio that you were unaware of! Like your file manager, which can play a custom "bell" for mandatory audio alerts when trying to type in a place that doesn't accept characters. Oops! Better close that down too and start 1-4 over again.

Restarting the computer is an easy and safe way to apply these changes. That people didn't follow all these steps in this exact way meant the computer started to break in strange and unobvious ways, not that it was ever supported.

If you want to help out designing smoother ways to change out core system components without reboots, feel free to do that. The people involved might not find it worth the trouble to fix, though. I think it's just sensible to restart the system.

Re: PipeWire and fixing the Linux Video Capture stack

#29

Post by dylan-m »

boudin wrote: post #17
pimeys wrote: post #10

I really wish Zoom could start using PipeWire for their screen sharing and video as soon as possible. Currently their desktop app gives a very interesting error if trying to share the screen from Wayland/sway. There is no need to only support Gnome on Ubuntu et.al. with PipeWire. The only way to use Zoom from my point of view is through their web app. And every time I start a meeting from their web interface, they're…

Their app is really bad. The good news is that their screen sharing based on gnome's private screenshot API should stop working altogether as Gnome 41 is securing those APIs. Their webapp is quite bad as well though and behind in features especially on Firefox on which, for whatever reason, there's no gallery mode. They should drop their crap desktop app and focus on building a descent webapp instead.

The weird screenshot thing also leads to confusing issues like this one: https://github.com/flathub/us.zoom.Zoom/issues/223. Zoom tries to avoid sharing its own windows by using an X window property that specifies the owning PID, so it filters out any window where `_NET_WM_PID == Zoom's PID`. In a modern Linux desktop where applications are sandboxed, many different applications can think they have the same PID, so it ends up filtering out other applications.

Not sharing its own windows is nice and all, but I don't think Zoom even does that on other platforms. It's weird how much effort they have put in to doing the wrong thing.

Re: PipeWire and fixing the Linux Video Capture stack

#30

Post by jmclnx »

I had to read the blog on lynx due to light grey text on white. I wish people will realize many people will have a hard time with that coloured text.

Well a bit concerning in a way. Does this change require GNOME and/or Wayland ? The way I read it it seems so, but little detail there.

I wonder because I use fvwm2 as opposed to Desktops, which I really do not like at all.

Post reply on HN