Hardware video decoding on S905X

[dreamlayers]

I have an OTT TV Box, model ABOX-A1 ( 1G + 8G, S905X ). It is running Armbian 23.11.1 bookworm. How can I have hardware video decoding?

 

Hardware video decoding support seems present in the 6.1.63-current-meson64 kernel. It seems only the V4L2 M2M API is present. Some firmware seems missing. I was getting "meson-vdec c8820000.video-codec: Direct firmware load for meson/vdec/gxl_h264.bin failed with error -2" in dmesg. I don't know what package I need to install. I was thinking maybe firmware-linux-nonfree, but that conflicts with armbian-firmware due to firmware-ralink. The files are available at https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/meson/vdec though, and I downloaded gxl_*.bin from there and put them in /lib/firmware/meson/vdec/ .

 

I've tried Kodi, mpv and ffmpeg, in Wayfire and at the text console. Kodi always uses lots of CPU, and mpv crashes whenever I use --hwdec=v4l2m2m-copy. The best result was "ffplay -vcodec h264_v4l2m2m file.mp4" at the console. That at least actually seems to use hardware decoding because I see this output: driver 'meson-vdec' on card 'Amlogic Video Decoder' in mplane mode. But the CPU utilization is actually worse, about 300%, compared to below 200% without -vcodec h264_v4l2m2m.

 

Edit: After installing mpv 0.37.0-1 and its dependencies from trixie (Debian testing), I definitely got hardware acceleration in mpv --hwdec=v4l2m2m-copy. CPU usage was less that 100% on one core. However, there were still problems with dropped frames and audio/video desynchronization, so I don't recommend this. Kodi CPU usage seems decreased too, often below 200% playing the same file, but this is still terrible for playing 720p H.264. It's not worth messing up your packages with a mix from two Debian versions only to get this.

 

Edit: The Kodi 2:20.1+dfsg-1 from Bookworm doesn't have the DRM PRIME options in "Settings > Player > Videos", so I guess it doesn't support acceleration? The Kodi 2:20.4+dfsg-1 from Trixie does have those options, and enabling them makes the video disappear. I've tried setting "PRIME Render Method" to EGL and Direct-To-Plane, and both failed in a similar way.

Edited February 19, 2024 by dreamlayers
Reporting partial success

[dreamlayers]

Later I installed an Ubuntu Noble 24.04 image. There, hardware decoding definitely works in mpv, via v4l2m2m-copy. There is a huge decrease in CPU usage. Though, frames are still dropped even though there is plenty of CPU time. That decoder can also be used from ffplay, also with dropped frames. This problem exists at the console, in Wayland and in X.

 

I figured out why Kodi DRM PRIME wasn't working. PRIME uses the dma-buf subsystem of the kernel, and that was turned off in the kernel configuration file.  After enabling

CONFIG_UDMABUF=y
CONFIG_DMABUF_HEAPS=y
CONFIG_DMABUF_HEAPS_SYSTEM=y
CONFIG_DMABUF_HEAPS_CMA=y

and recompiling the kernel, I could use DRM PRIME, both on the S905X ABOX-A1 and on a S912 based X92. The S912 had corruption in the video when rendering to EGL, so there DRM PRIME was only usable outside of Wayland, using Direct to Plane. There was no such problem on the S905X.

 

(As mentioned earlier, hardware decoding also needs vdec firmware: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/meson/vdec )

 

Even after all this, Kodi still uses software decoding for some reason. Pressing o during playback, I see that it is indeed using PRIME, but software decoding. I don't know why.

 

Generally, this is a nightmare to troubleshoot, because there is often a lack of clear log or error messages that describe the problem.

 

Edit: I downloaded LibreELEC-AMLGX.aarch64-12.0.1-box.img.gz. In the root directory of the FAT32 boot partition of the image is the SYSTEM file, a squashfs of the whole LibreELEC system. (There is nothing in the second partition.) I used unsquashfs to extract the SYSTEM file, and then mount --bind to make /dev, /proc, /sys and a directory with media files accessible inside the extracted squashfs-root. I could then run squashfs-root/usr/lib/kodi/kodi.bin in a chroot, and get hardware acceleration. Though USB input devices need to be replugged to be usable, and there is no way to exit that Kodi, so this is not ideal.

 

Then I copied libavcodec, libavdevice, libavfilter, libavformat, libavutil and libswresample from squashfs-root/usr/lib/ into new directory ffm and started Armbian Kodi via LD_LIBRARY_PATH=ffm kodi. This gave me hardware acceleration in Armbian Kodi. So, it seems that some issue with FFmpeg libraries prevents hardware acceleration in Armbian Kodi.  This solution is fine for now, giving smooth hardware accelerated playback with minimal CPU usage.
 

 

 

Edited December 27, 2024 by dreamlayers
Found a good workaround