Pipeline no longer works on Ubuntu 26.04

pipewiresrc path={path} keepalive-time=50 ! video/x-raw,width={width},height={height},max-framerate=120/1 ! queue max-size-buffers=2 leaky=downstream silent=true ! nvh265enc bitrate=25000 max-bitrate=26000 gop-size=30 zerolatency=true preset=p1 tune=ultra-low-latency rc-mode=cbr ! rtph265pay pt=96 mtu=1200 config-interval=1 ! udpsink host={ip} port={port} sync=false

udpsrc port=%d buffer-size=4194304 caps=“application/x-rtp, media=video, encoding-name=H265, payload=96” ! rtpjitterbuffer latency=30 ! rtph265depay ! h265parse disable-passthrough=true ! amcviddec-c2qtihevcdecoderlowlatency name=decoder ! video/x-raw(memory:GLMemory) ! glimagesink sync=false name=unity enable-last-sample=false qos=false rotate-method=horizontal-flip

These 2 pipelines work perfectly on Ubuntu 24.04 but on 26.04 no longer function correctly. Whenever a painting update is done be it highlight changes, dragging a window, the stream updates at a consistent framerate.

When there are no painting updates such as moving the mouse around no updates are made. The mouse appears frozen in place until a paint update needs to be made.

What might be causing this and how do I fix it?

Ubuntu 26

gst-launch-1.0 --gst-version
GStreamer Core Library version 1.28.2

pipewire --version
pipewire
Compiled with libpipewire 1.6.2
Linked with libpipewire 1.6.2

Ubuntu 24

gst-inspect-1.0 --version
gst-inspect-1.0 version 1.28.1
GStreamer 1.28.1 (GIT)

pipewire --version
pipewire
Compiled with libpipewire 1.7.0
Linked with libpipewire 1.7.0

And yes I know the first thing I should try is get pipewire 1.7 onto Ubuntu 26 to rule it out but I highly doubt this is the issue. It worked fine on Ubuntu 24 on lower pipewire versions and I can’t find any evidence of a bug like this being fixed in pipewire between 1.6 and 1.7.

I have updated to pipewire 1.7.0 on Ubuntu 26 and still observe the same broken behavior.

Here is a video showing the incorrect behavior

ScreencastFrom2026-05-0816-51-49-ezgif.com-video-to-webp-converter-1

I’m pretty sure this is something broken in Ubuntu after playing around with it more.

After playing with it even more I’m not so sure anymore. I made a bug in mutter for reference: Work items · GNOME / mutter · GitLab

I’ve found that restarting every GStreamer stream after creating a new monitor fixes it so now I’m not sure if this is a weird bug in GStreamer or something to do with Mutter updates.

I’m still no closer to figuring out what’s going wrong here. Restarting the streams on every monitor change is not ideal and also doesn’t work properly. Frequently streams show very choppy frame rates and it takes numerous restarts to get the full framerate. Streams are also prone to randomly stopping for no apparent reason with nothing obvious in the logs.

I’ve discovered that in GNOME 50 options were added to allow virtual monitors to be resized in the system display options controls. Virtual monitors now renegotiate pipewire nodes on display changes: Client Challenge

GStreamer does not handle this renegotiation well and freezes up. It remains frozen until restarted. My workaround is to currently poll for monitor changes and restart all sender processes when a change happens.