Skip to main content


Friends of energy efficiency - the Light Video 0.1.0 #Flathub update is out, build with #gtk4 4.14 and #GStreamer 1.24.1.

This should be the first app targeting the #linux / FDO desktop enabling Wayland video offloading (think zero-copy playback) by default. In many cases (actually more than I expected) this can improve battery lifetime - and on low-end devices even playback performance - significantly.

https://flathub.org/apps/org.sigxcpu.Livi

This entry was edited (1 month ago)
in reply to Robert Mader

This is kinda a technology preview in order to see if we can ship features like this enabled by default in a lot more apps in the ecosystem.

Thus I'd be very super happy if you'll try it on lots of hardware - be Intel/AMD laptops or ARM64 devices (with V4L2 stateless decoders, such as most #LinuxMobile devices).

Chances that you really hit a zero-copy path are highest with a recent #Wayland compositor - i.e. if you are using #GNOME46, #kde6 or a recent version of #sway, #weston, #cosmic etc.

This entry was edited (1 month ago)
in reply to Robert Mader

Note that there are still a number of limitations to offloading to KMS/display controllers. In these cases Livi should fall back just fine and will just be less efficient.
I hope we can lift them step by step. A few of them being:
- only hardware decoded video, not sw decoded
- only VA-API or V4L2-stateless, no V4L2-stateful or Vulkan yet (but at least the later should fall in place naturally)
- depending on the compositor and hw: only if the display dimensions match the video, e.g. 16:9
in reply to Robert Mader

As well as only working when nothing is rendered on top of the video, like overlays, subtitles etc. Note that this limitation comes purely from HW/compositors - from the app side it is supported and works quite well on e.g. #weston, which already implements sophisticated hw plane management.
in reply to Robert Mader

I guess I should have elaborated a bit more why and what for I'm asking for testing. So my main goal is to find remaining cases where the output looks like one of the attached images, which are complete deal breakers for users.

These are usually driver bugs - in Mesa or the kernel - and optimally should get reported accordingly. But if you see something like this are you are not sure where to report it - please feel free to DM me!