Hacker News Reader

Comment by blakesterz | Hacker News Reader

I like the "What's PipWire" intro, I had no idea what it was, and now I get it. It starts with this nice explanation:

"PipeWire is a media processing graph, this might not ring a bell so let me rephrase. PipeWire is a daemon that provides the equivalent of shell pipes but for media: audio and video."

I've so many projects that still made no sense after reading the ABOUT or README, this one does a nice job of explaining.

View on HN

It's not clear to me what Pipewire does with respect to video. The audio part makes sense, most talk of pipewire that I've seen focuses on using pipewire as a replacement to pulseaudio. But what exactly does it do for video? I assume pipewire doesn't replace video playing applications like mpv. Would mpv use pipewire in place of some other component? Would/could mpv use pipewire in place of ffmpeg? Or is pipewire for video something like a wayland compositor?

The original use case for pipewire was video, it was originally named "PulseVideo". It allows things like using an application running on Wayland as a video source and piping it into Firefox so you can share your screen on Zoom or something similar.

I'm not sure if you've read this or not, but there was a little information on the Arch wiki, here: https://wiki.archlinux.org/title/PipeWire#WebRTC_screen_shar...

The fact that it's a filter graph for shuttling buffers between sources and sinks lends itself to both buffers for audio and buffers for video. An application that generates video frames could decide to send its video frames to pipewire, and an application that accepts video frames could accept them from pipewire.

This is how screensharing through xdg-desktop-portal (linked in my sibling comments) works. The xdp implementation gets screencapture frames from the compositor and pushes them into pipewire, and the screensharing application (browser, etc) pulls the frames from pipewire.

This isn't new; DirectShow on Windows, and its successor Media Foundation, are also based on graphs. Put "windows graphedit" and "windows topoedit" in an image search engine for examples.

Arnavion got it right, but a simpler case is that you would be able to share your webcam or video streams with multiple applications at the same time, while also allowing you to insert filters or modification of that video on the fly. Similar to how you can do that with audio servers right now.

this PR https://github.com/obsproject/obs-studio/pull/4287 suggests OBS uses it for wayland screen capture.

It does the same thing it does for audio: routes and multiplexes streams. Video devices in Linux the same problem as audio devices where multiple applications can't have them open at the same time. Pushing the video through a daemon also allows you to do the same interesting things that you can do with audio streams in pulseaudio/jack, where you can transparently change the inputs and outputs around without having to restart or reconfigure the application, and you can route video through arbitrary effect chains before it reaches the destination.

If the application can use v4l devices directly (I think this includes all ffmpeg players such as mpv) or can output a video stream somewhere, then it might make sense to also add a pipewire backend there. Maybe somebody will make this easy by adding a pipewire encoder/decoder to ffmpeg? Then the applications won't have to do much at all to support this. If the application uses gstreamer, you may already be able to get it to work automatically by using pipewiresink/pipewiresrc.

One can do modular audio synthesis with JACK+LV2; https://github.com/mxmilkiib/carla-lv2-jack-nsm

wtay has mentioned that PipeWire will be able to allow for system-wide video synthesis; https://youtu.be/PIgPIrYq-Pc

And https://gitlab.freedesktop.org/ryuukyu/helvum

Reply on news.ycombinator.com