Robert Mader

> Please, reminder that for stateless decoders, there is an extra /dev/mediaX device that needs to be available. Uh, good point - but that should be possible with the same...

If we were to drop the language prefix in the urls we could simply drop it.

Well that's most likely an upstream issue. Firefox can't get out of the sandbox flatpak provides. So there would need to be a portal (see https://github.com/flatpak/xdg-desktop-portal), which either allows firefox...

It's probably noteworthy that Pipewire support is still not enabled by default in upstream Chromium, see https://www.phoronix.com/news/Wayland-Chrome-Screen-Share-22. So maybe it's a deliberate decision to wait for things to stabilize first...

Gave it a quick try with https://gitlab.gnome.org/rmader/gtk/-/commits/issue4062 (from https://gitlab.gnome.org/GNOME/gtk/-/issues/4062#note_2093829), but that'll need a bit more debugging. That being said, with just the first commit things work quite well already for...

I gave this a try on top of https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7186 - *sometimes* it works and plays videos fine, but usually it crashes with: ``` libsoup:ERROR:../libsoup/cache/soup-cache-input-stream.c:154:soup_cache_input_stream_write_next_buffer: assertion failed: (priv->output_stream && !g_output_stream_is_closed (priv->output_stream))...

P.S.: thanks for the explanation, that makes a lot of sense!

> For the sake of not blocking it from the GTK side, I wrote a small reproducer that uses GFile but with inputstream > ... > Unfortunately, I see it's...

> I experimented with libsoup threading but I faced other problems (plus libsoup is not entirely thread-safe) 🙃 Just wanted to drop that I wonder if using the Gstreamer `souphttpsrc`...

Thanks, this looks great! Gave it a try and see one more issue: the fullscreen toggle button doesn't reliably automatically hide with the other window controls yet - and when...