floss.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
For people who care about, support, and build Free, Libre, and Open Source Software (FLOSS).

Administered by:

Server stats:

686
active users

Regarding the future of video playback in I'd like to add some more context around current developments in , and 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 (floss.social/@rmader/111142297). Recently devs picked things up and implemented compositor offloading, see their nice blog post: floss.social/@GTK/111415523629

We're now working on filling the remaining gaps so this can become an actual reality on the (and generally / / ) 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.

Robert Mader

Take for example these examples of a (rk3399 / v4l2 stateless) playing 4k content or the 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 .

My hope is that we can ship some initial support for all of this in - if possible with the default video player. Be it Totem, ported to , 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, clients like Tuba or camera apps like / Snapshot (for a battery friendly viewfinder - important on ). 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 , 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 recently got funding from the . One of the sponsored projects is to implement GL robustness in / 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 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 , , , , 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 -> 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 default video player, with lots of great answers: floss.social/@rmader/111450167

- some WIP GTK patches: gitlab.gnome.org/GNOME/gtk/-/m

- some WIP Mutter patches: gitlab.gnome.org/GNOME/mutter/

I'm also looking for people to help with caps negotiation in various elements, especially for V4L2 decoders :)

GitLabgstsink: Add support for DMABuf import and graphics offload (!6618) · Merge requests · GNOME / gtk · GitLabBy implementing support for GdkDmabufTextureBuilder and GstVideoInfoDmaDrm. This allows zero-copy video playback on Wayland when paired with hardware video decoding. Can be tested with gtk4-demo --run=video_player...

@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 blogs.gnome.org/a11y/2023/10/2

blogs.gnome.orgA new accessibility architecture for modern free desktops – GNOME Accessibility