rmader,
@rmader@floss.social avatar

For those of you interested in our recent video offloading / zero-copy playback work: I quickly put together some 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 :)

A picture of a PinePhone Pro easily and smoothly playing a 4k@60fps VP9 video.

rmader,
@rmader@floss.social avatar

Things should generally work on , , and - not sure about other compositors.

I haven't tried myself yet as NV12 support was only added recently. But tomorrow there's a local release party where I hope to convince some people to try on their devices.

rmader,
@rmader@floss.social avatar

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.

rmader,
@rmader@floss.social avatar

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.

rmader,
@rmader@floss.social avatar

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.

rmader,
@rmader@floss.social avatar

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 basely of the minimal required GPU work (assuming compositors are fully optimized).

rmader,
@rmader@floss.social avatar

For those using HW that still uses the stateful V4L2 API for decoding - such as the - I uploaded another build to the link in the first post that includes a 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

The video shows a Gnome desktop running on a Raspberry Pi 4, using a screen with a resolution of 2560x1440 pixels. A 1080p@30fps video is played with the mentioned livi player build. While the video is choppy when the video overlay is visible, it becomes fully smooth once the overlay is hidden and zero-copy playback using the display controller hardware plane is used and the 3D engine can be skipped.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • linuxphones
  • DreamBathrooms
  • ngwrru68w68
  • modclub
  • magazineikmin
  • thenastyranch
  • rosin
  • khanakhh
  • InstantRegret
  • Youngstown
  • slotface
  • Durango
  • kavyap
  • mdbf
  • GTA5RPClips
  • provamag3
  • ethstaker
  • normalnudes
  • tester
  • osvaldo12
  • everett
  • cubers
  • tacticalgear
  • anitta
  • megavids
  • Leos
  • cisconetworking
  • JUstTest
  • lostlight
  • All magazines