On úterý 3. února 2026 21:36:48, středoevropský standardní čas Laurent Pinchart wrote: > On Tue, Feb 03, 2026 at 04:53:41PM +0200, Laurent Pinchart wrote: > > On Tue, Feb 03, 2026 at 03:38:06PM +0100, Oleksandr Natalenko wrote: > > > > > > Just to share my current state of affairs: > > > > > > * sender: > > > > > > $ gst-launch-1.0 pipewiresrc path= ! video/x-h264, width=1280, height=720, framerate=24/1 ! rtph264pay ! rtpstreampay ! udpsink host= port= > > > > > > * receiver: > > > > > > $ gst-launch-1.0 udpsrc address= port= ! queue ! application/x-rtp-stream,encoding-name=H264 ! rtpstreamdepay ! application/x-rtp,encoding-name=H264 ! rtph264depay ! h264parse ! openh264dec ! pipewiresink mode=provide stream-properties="properties,media.class=Video/Source,media.role=Camera" client-name=VirtualCam > > > > > > I chose H.264 because of much lower (tenfold) traffic comparing to > > > MJPEG, wrapped this into RTP, opted in for OpenH264 decoder because I > > > read it was handling low latency streams better than avdec_h264, and > > > tested this setup with both Firefox and Chromium, and it actually > > > worked pretty reliably, so I'm impressed now. > > > > Thank you for the update. I'll give this a try. > > I've tried those, but as soon as Firefox is connecting, I get > > 0:00:03.569028999 131465 0x7f85cc002030 DEBUG pipewiresink gstpipewiresink.c:692:on_state_changed: got stream state "error" (-1) > 0:00:03.569060959 131465 0x7f85cc002030 DEBUG pipewiresink gstpipewiresink.c:692:on_state_changed: got stream state "error" (-1) > 0:00:03.569070767 131465 0x7f85cc002030 WARN pipewiresink gstpipewiresink.c:710:on_state_changed: error: stream error: no more input formats > ERROR: from element /GstPipeline:pipeline0/GstPipeWireSink:pipewiresink0: stream error: no more input formats > Additional debug info: > ../pipewire-1.4.9/src/gst/gstpipewiresink.c(710): on_state_changed (): /GstPipeline:pipeline0/GstPipeWireSink:pipewiresink0 > > Maybe I should try the pipewire master branch. I'd be glad to help, but my understanding of this "stream error: no more input formats" boils down only to the absence of caps identifiers (like those "application/x-rtp-stream"blahblah), which is not the case here. Also, Firefox behaves differently from Chrome when using sites like webcamtests, and also when using google meet. I may speculate Firefox more eagerly closes link to a pipewire node, but I have no knowledge of this at all. That said, "pretty reliably" doesn't mean without issues whatsoever, and I manage to crash both Chrome and Firefox from time to time while experimenting with pipelines. Probably because I occasionally unintentionally feed some crap into the pipewire sink. FWIW, I'm using 1:1.4.10-2 pipewire packages from Arch. -- Oleksandr Natalenko, MSE