Does Dietpi firmware support Rockchip MPP for VPU video decoding? (for Radxa Rock-3a | RK3568)

Guasi · 15 July 2025 10:00

Hello.
I have a Radxa Rock-3a (on the SOC Rockchip RK3568 base).
It has a VPU a decoder that supports hardware decoding/coding of the H264/H265 video.
I want to use FFMPEG with decoders via VPU.
I read that for this you need a module MPP (GitHub - rockchip-linux/mpp: Media Process Platform (MPP) module).
Does Dietpi have a firmware for Rock-3A support for hardware decoding video for FFMPEG?

Joulinar · 16 July 2025 10:45

maybe @MichaIng knows

MichaIng · 16 July 2025 16:36

Up to RK33xx, the VPU is well supported by the mainline Linux Hantro driver.

For RK356x, where we ship images with mainline Linux as well, we get mixed feedback, but H264 should work. There are or were quite some patches offered upstream to extend features/support, but AFAIK H265 is still missing, not sure about the status of JPEG and VP9.

PINE64 provides some contradicting status info:

Maybe better check source code of the driver for hints:

Our current branch based on Linux 6.12: Making sure you're not a bot!
Our edge branch based on Linux 6.16: Making sure you're not a bot!

In any case, the driver provides a different API, not the Rockchip MPP, so software needs to support it as well.

For RK3588, while there are bits and pieces in the mainline driver already, AFAIK it is not well supported yet. Our images for those boards however ship with vendor kernel based on Rockchip Linux 6.1, hence with Rockchip MPP driver. This kernel can be generally also installed on RK356x SBCs, but so far we have not added it to our APT repo for those, and I am hesitating to make this legacy Linux version prominently available. But you can find the packages with vendor-rk35xx suffix here: Index of /downloads/binaries

Always install both, image + dtb packages.
There might be some cases where mainline Linux does not boot with vendor U-Boot vice versa, depends on exact SBC, so to be safe, find the u-boot-...-vendor package as well, and flash that U-Boot via dietpi-config advanced options.

Guasi · 18 July 2025 20:32

Thank you very much for the detailed answer.
I installed packages
Linux-Image-nedor-rk35xx.deb
linux-dtb-wendor-rk35xx.deb
Linux-libc-dev-rek35xx.deb

The Linux-U-Boot-Rock-3A-Current.deb package has already been installed.

I collected FFMPEG from the instructions Compilation · nyanmisaka/ffmpeg-rockchip Wiki · GitHub
But the results have not yet impressed - CPU is loaded. I expected that the CPU boot would be much less.
Perhaps this is the norm and it should be, I will find out further on the Radxa forum.

libx264
ffmpeg -i h264_1080p_30fps_1.mp4 -c:v libx264 -profile:v main -c:a copy -vf "scale=1280:720" output.h264_1080p_30fps_1.mp4
speed=0.48x
cpu=98-100%

ffmpeg -i hevc_1080p_24fps.mp4 -c:v libx264 -profile:v main -c:a copy -vf "scale=1280:720" output.hevc_1080p_24fps.mp4
speed=0.23x
cpu=98-100%

rkmpp
ffmpeg -i h264_1080p_30fps_1.mp4 -c:v h264_rkmpp -profile:v main -c:a copy -vf "scale=1280:720" output.h264_1080p_30fps_1.mp4
speed=1.43x
cpu=64-68%

ffmpeg -i hevc_1080p_24fps.mp4 -c:v hevc_rkmpp -profile:v main -c:a copy -vf "scale=1280:720" output.hevc_1080p_24fps.mp4
speed=1.3x
cpu=90-92%

Guasi · 19 July 2025 09:26

I did not use RKMPP correctly, need to add HWACCEL:

ffmpeg -hwaccel rkmpp -hwaccel_output_format drm_prime -afbc rga -i h264_1080p_30fps_1.mp4 -c:v h264_rkmpp -c:a copy output.h264_1080p_30fps_1.mp4

speed=1.92x
cpu=11-14%

ffmpeg -hwaccel rkmpp -hwaccel_output_format drm_prime -afbc rga -i hevc_1080p_24fps.mp4 -c:v hevc_rkmpp -c:a copy output.hevc_1080p_24fps.mp4

speed=3x
cpu=13-16%

Guasi · 19 July 2025 09:45

A couple of examples:

ffmpeg -hwaccel rkmpp -i h264_1080p_30fps_1.mp4 -c:v h264_rkmpp -c:a copy output.h264_1080p_30fps_1.mp4
CPU governor settings: performance
speed=1.59x
cpu=11-13%
real 0m50,478s
user 0m11,311s
sys 0m11,394s

ffmpeg -hwaccel rkmpp -hwaccel_output_format drm_prime -afbc rga -i h264_1080p_30fps_1.mp4 -c:v h264_rkmpp -c:a copy output.h264_1080p_30fps_1.mp4
CPU governor settings: performance
speed=2.38x
cpu=4-7%
real 0m33,651s
user 0m3,311s
sys 0m2,894s

anika200 · 19 July 2025 20:57

I hope this is not too far off topic but there is a great discussion at the blog thread I link too, read the article first and then the comments are actually the most enlightening and even more up to date. All about rk35xx chips.
https://www.collabora.com/news-and-blog/news-and-events/rockchip-rk3588-upstream-support-progress-future-plans.html

anika200 · 19 July 2025 22:59

It is nice that you posted this comparison, very helpful and informative. Thank you.

usual-user · 20 July 2025 14:36

FWIW
Current information on the development status for the rk3588 SoC is published here.

Since I was tired of being frustrated with the limited RAM capacity of my ODROID-N2+ (S29X SoC) — 4GB is simply too little for desktop applications like memory-hungry web browsers — I recently purchased an ODROID-M2 (rk3588s SOC). The device came as expected without suitable firmware that can handle common bootflows. Fortunately, the mainline firmware support is already available out-of-the-box, so only a corresponding build was required. I was surprised to see a kernel starting while trying to test my first firmware build, but I had overlooked that I was using a microSD card with which I had previously tested a jumpstart image that I had created for someone else to bypass a USB initialization issue on an ODROID-N2+. So I shut down my ODROID-N2+, it is currently running my latest operating system from an USB enclosure with an included NVME SSD. Disconnected the USB enclosure from the ODROID-N2+, plugged it into the ODROID-M2, and turned it on. About 30 seconds later, I was confronted with this:

And no, I haven’t forgotten to mention it, I have made no modifications to the OS or the bootflow. It was planned to replace the ODROID-N2+ with the ODROID-M2 in the long term, but so far I haven’t switched back here even once:

The M2 works significantly better than the N2+, although no device-specific modifications were applied. And with the performance, it far surpasses my ODROID-M1 (rk3568), which has been functioning equivalently for a long time:

I had expected a significantly more extensive bring-up based on the current statements circulating on the internet, but with current software, it was child’s play. The fact that some video decoder support is still missing (hantro support is already available) is only secondary; for desktop applications, even software decoding is acceptable since even 4K content is usable. Only the fan, which runs due to CPU load, can be potentially annoying. But the mainline support is just around the corner.

MichaIng · 23 July 2025 19:04

What I meant is the linux-u-boot-*-vendor package. Though it might not even exist, since we do not usually build vendor packages for those models. Anyway, glad it does not seem to be required in this case.

If you do not use libx264 software codec explicitly on mainline Linux, it is used regardless?

I am not certain whether mainline FFmpeg can make use of mainline Linux Hantro VPU driver or not. There is a patchset by Kwiboo waiting since 2019, which adds support for the newer V4L2 Request API, but has not been merged til today:

A 3rd party APT repo provides FFmpeg builds for current Debian and Ubuntu versions with this added: Repository for v4l2request hardware video decoding (rockchip, allwinner) - Reviews, Tutorials, Hardware hacks - Armbian Community Forums

But I am not sure whether this is the only way to utilize the VPU with FFmpeg, at least on older SoCs than RK3588.