Recent searches
Search options
Administered by:
For those of you interested in our recent video offloading / zero-copy playback work: I quickly put together some #livi #flatpak s to make it easy to test stuff already. Compositor offloading should work on all semi-recent Intel/AMD and a variety of ARM64 devices.
If you trust the sandbox you can get them here:
https://cloud.silentundo.org/s/r8733siTjP4yRJp
I expect quite a few people hitting driver bugs, so please help tracking those down :)
Note that offloading currently requires HW decoding - something I hope we can change next cycle. #livi will display a little icon in the top-left if hardware decoding and thus offloading is not used.
Whenever HW decoding and offloading works I'd expect the player to be competitive to whatever other favorite player you have performance wise.
Everything in the Flatpak is either already upstream or close to it, the missing bits being
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5890
and
https://gitlab.gnome.org/guidog/livi/-/merge_requests/35
I hope to have both shipping with the upcoming spring release distros.
For those that are confused by the pictures in the first post because they know about the hardware limitations: yes, correct, both of them actually don't show zero-copy playback :P
One semi-surprising finding of the offloading work was that compositor offloading often pays off even when not hitting a full zero-copy path / hardware plane scanout.
In theory that gap shouldn't exist and we more or less have all APIs in place to let clients scale and pre-rotate content in a optimal way - i.e. so the compositor doesn't have to do a copy and we keep things to one single copy wherever zero-copy is impossible.
In practice there's lots of room for improvements in various stacks. With compositor offload we now have a baseline of the minimal required GPU work (assuming compositors are fully optimized).
For those using HW that still uses the stateful V4L2 API for decoding - such as the #RaspberryPi4 - I uploaded another build to the link in the first post that includes a #GStreamer patch that is *not* close to landing, but works well enough to make playback work.
With that I can play 1080p30fps videos (the decoder limit) on my big screen smoothly, which otherwise not possible (apart from reducing the resolution).
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6114
P.S.: please ignore the glitches and missing elements, that's temporary issues :P
Edit: updated the build with a workaround for some of the glitches.
Edit2: in case you want to follow:
https://gitlab.gnome.org/GNOME/gtk/-/issues/6498
https://gitlab.gnome.org/GNOME/gtk/-/issues/6499
@rmader That reminds me that this seems like a regression with the switch away from the proprietary Broadcom GL stack and the OpenMAX IL/MMAL-based decoders.
With those (even on the RPi 1/2/3!) it was possible to decode and render 1080p30 smoothly by getting EGLImages from the decoder and rendering them via GLES2.
With the new Mesa/VC4 GL stack and the v4l2-based stateful decoder this is only possible by directly rendering the dmabufs via KMS or Wayland instead of going via anything GL-based.
I didn't investigate this further.
@slomo I have to say that when I reduce the screen resolution to 1080p it probably work if it wasn't for https://gitlab.freedesktop.org/mesa/mesa/-/issues/10306 (direct scanout broken for GL apps).
But for anything above I'd assume things to get problematic without hardware plane upscaling. Maybe it would still manage 30fps, but likely with an extra frame latency on a 60fps screen.
@rmader Ah that's a good hint. Thanks!
@rmader what is compositor offloading?