Recent searches
Search options
Administered by:
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.
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.
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
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.
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!
If you want to check whether Livi is actually using zero-copy, there's unfortunately not one single way, but different ones depending on the hardware and compositor you use.
One Intel or AMD a simple way is to use intel_gpu_top or radeontop via ssh and check whether the 3D parts of the GPU are reported being idle, such as in the first post.
If you run Gnome, you can enable the opaque region overlay, which draws green or purple overlays over the content whenever Mutter is compositing - and shows the content normally when doing direct-scanount / zero-copy.
You can enable it via alt+f2 -> "lg" -> "Flags" -> OPAQUE_REGION
When things work correctly, you should get a purple overlay when in windowed mode or player controls are visible - and a normal image when fullscreen without controls.
This means Livi/GTK offloads the video and draws controls etc. in an overlay (that's mostly transparent). Mutter doesn't support multiple hardware planes yet and has to fall back to compositing. But if only the video is visible, it can pass things through.
If the whole player is either greenish or there's no overlay at all, despite controls being visible, that means that GTK is not offloading but drawing the video via GL/VK. Mutter may or may not be able to use direct-scanout in this case.
@rmader ah yeah I get the greenish tint unfortunately. I'm on a Lenovo Yoga 920 with Intel UHD 620 graphics and running Fedora 40 fwiw. :)