Regarding the future of video playback in #gnome I'd like to add some more context around current developments in #gnomeshell, #gtk4 and #Wayland in a short
TL;DR: by making use of more modern hardware features we're finally in the position to catch up to other platforms with regards to energy efficiency. So let's do it!
In a previous thread I wrote about YUV support in Mutter having made its way into #gnome45 (https://floss.social/@rmader/111142297368297062). Recently #gtk4 devs picked things up and implemented compositor offloading, see their nice blog post: https://floss.social/@GTK/111415523629484640
We're now working on filling the remaining gaps so this can become an actual reality on the #gnome (and generally #linux / #fdo / #gnu) desktop. And what can I say - things actually work out quite nicely! While on modern Intel or AMD systems the effect is mostly about lower resource consumption, on some low-end hardware there are visible differences on what you can play fluently.
Take for example these examples of a #PinebookPro (rk3399 / v4l2 stateless) playing 4k content or the #RaspberryPi 4b (v4l2 stateful / m2m) playing 1080p@60fps (the limit of the hardware decoder) on a 2560x1440 screen. My videos probably don't fully capture the effect, but especially in the later case the difference is pretty visible). This is using the gtk video player demo with some extra patches and #gstreamer.
My hope is that we can ship some initial support for all of this in #gnome46 - if possible with the default video player. Be it Totem, ported to #gtk4, or some alternative. The goal is of course that as many apps as possible can make use of it without much hassle - be it video streaming apps, video chat apps like @dino or Fractal, #fediverse clients like Tuba or camera apps like #gnomecamera / Snapshot (for a battery friendly viewfinder - important on #linuxmobile). And of course browsers.
Making this all work is a long process and when talking to people that have been working in the field longer than me, I often get the feedback to be not too optimistic regarding time frames. As always when pushing some limits there will be driver bugs, missing APIs and loose ends all over the place. So far every device I tried needed at least some fixes in #mesa, the kernel or both. And when things break, we have to be extra careful to not impact stability.
That's why we're very fortunate that #gnome recently got funding from the #SovereignTechFund. One of the sponsored projects is to implement GL robustness in #gnomeshell / Mutter, so if the driver stumbles when trying to import some unusual buffer you won't lose your session.
My personal vision with all of this is to see #wayland desktop technologies not only catching up with what other OSs offer, but becoming leading players - just like what other FLOSS projects already archived (or are in the process of becoming) in their areas. I'm thinking of #mesa, #pipewire, #gstreamer, #systemd, the kernel of course, and many others.
The plan is as usual: expose exciting technology to a great community of technical capable people -> improve quality, reliability and features (HDR...) -> get more companies to use it for products and invest into its development -> repeat -> #wayland world domination :P
Yeah, quite optimistic. Let's see how it goes. End
P.S.: totally forgot - if you want to follow the development, try things out or even consider helping, here are some links:
- the previous thread about the #GNOME default video player, with lots of great answers: https://floss.social/@rmader/111450167627181127
- some WIP GTK patches: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6618
- some WIP Mutter patches: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177
I'm also looking for people to help with #Gstreamer caps negotiation in various elements, especially for V4L2 decoders :)
@rmader Similarly, with the new free desktop accessibility architecture I started prototyping last week, my goal is for accessibility on free desktops to leap ahead of the proprietary platforms in some ways, not just catch up. See https://blogs.gnome.org/a11y/2023/10/27/a-new-accessibility-architecture-for-modern-free-desktops/