RK3576 - Support for full video hardware acceleration on Armbian

[Marus Gradinaru]

Hi !

I have a FriendlyElec NanoPi M5 and I want to play movies with it. But I want to squeeze everything out of this SBC ! So, I need hardware acceleration.

I tested first with a OS image downloaded from FriendlyElec and mpv and (almost) everything works well. The mpv working configuration is: hwdec=rkmpp, vo=gpu, gpu-api=opengl. But I don't like that OS for other reasons, so I switched to Armbian. I installed the image "Armbian 26.5.1 KDE Wayland (Ubuntu 26.04 - vendor 6.1.115)", then I installed mpv, but when I try to play movies, it says:

 

marus@nanopi-m5:/mnt/NAS/WDRed1/Samples/FullHD$ mpv --hwdec=rkmpp --vo=gpu --gpu-api=opengl H265.8bit.FullHD.1920x816.24fps.10Mbps.SDR.mkv
● Video  --vid=1  --vlang=eng  'Carlito's Way 1993' (hevc 1920x816 23.976 fps) [default]
● Audio  --aid=1  --alang=eng  'DDP 5.1 ch 640 Kb/s' (eac3 6ch 48000 Hz) [default]
Unsupported hwdec: rkmpp
AO: [pipewire] 48000Hz 5.1(side) 6ch floatp
VO: [gpu] 1920x816 yuv420p
AV: 00:00:14 / 00:01:59 (12%) A-V:  0.000 Cache: 104s/146MB
Exiting... (Quit)

 

It seems that this mpv doesn't know about rkmpp's existence... Strange ! What can I do ? 

Has anyone managed to play movies with mpv and full hardware acceleration on NanoPi M5 and Armbian OS?

[Marus Gradinaru]

I've made some progress in debugging the mpv error... 

I introduced some additional debug display instructions into the mpv source code, so I could see what was actually happening. And here is the new log:

 

[vd] Codec list:
[vd]     hevc - HEVC (High Efficiency Video Coding)
[vd]     hevc_rkmpp (hevc) - Rockchip MPP (Media Process Platform) HEVC decoder
[vd]     hevc_v4l2m2m (hevc) - V4L2 mem2mem HEVC decoder wrapper
[vd] Opening decoder hevc
[vd] Looking at hwdec hevc_rkmpp-rkmpp...
ctx->hwdec_devs = 0xffff64347e20
[vo/gpu] Loading hwdec drivers for format: 'drm_prime'
[vo/gpu] Loading hwdec driver 'drmprime'
[vo/gpu/drmprime] Using EGL dmabuf interop via GL_EXT_EGL_image_storage
[vo/gpu/drmprime] Using DRM device: /dev/dri/renderD128
[vo/gpu/drmprime] ADDING DRMPRIME DEVICE
[vo/gpu/drmprime] hw->devs=0xffff64347e20
[vo/gpu/drmprime] av_device_ref=0xffff64348860
ADD: ctx=0xffff6434af60 hw_imgfmt=1057 type=8 av_device_ref=0xffff64348860
num_hwctxs=1
[vo/gpu/drmprime] DEVICE ADDED
[vo/gpu] Loading hwdec driver 'drmprime-overlay'
[vo/gpu/drmprime-overlay] Failed to retrieve DRM fd from native display.
[vo/gpu] Loading failed.
Searching: hw_imgfmt=1057 device_type=12 (rkmpp) num_hwctxs=1
ENTRY 0: ctx=0xffff6434af60 av_device_ref=0xffff64348860 hw_imgfmt=1057 type=8 (drm)
hw_ctx = (nil)
[vd] Could not create device.
[vd] Using software decoding.
[vd] Detected 8 logical cores.
[vd] Requesting 9 threads for decoding.
[vd] Selected decoder: hevc - HEVC (High Efficiency Video Coding)
[vd] DR parameter change to 1920x1088 yuv420p align=64
[vd] Allocating new (host-cached) DR image...
[vo/gpu] DR path suspected slow/uncached, disabling.
[vd] ...failed..
[vd] DR failed - disabling.
[vd] Using software decoding.
[vd] Decoder format: 1920x1080 yuv420p bt.709/bt.709/bt.1886/limited/auto CL=mpeg2/4/h264 crop=1920x1080+0+0 A=none
[vd] Using container aspect ratio.
[vo/gpu] reconfig to 1920x1080 yuv420p bt.709/bt.709/bt.1886/limited/display CL=mpeg2/4/h264 crop=1920x1080+0+0 A=none
[vo/gpu/wayland] Reconfiguring!
[vo/gpu] max content size: 1024x600
[vo/gpu] monitor size: 1024x600

 

The result says exactly this:

  VO (drmprime): add a DRM type device

  Decoder (rkmpp): look for an RKMPP type device

  => can't find it
  => hw_ctx = NULL
  => Could not create device
  => decoding software

 

More precisely: ADD:  hw_imgfmt = 1057  type = DRM

and immediately after: Searching:  hw_imgfmt = 1057  device_type = RKMPP

So the problem is not: The MPP, FFmpeg, mpv does not create hwdec_devs, drmprime driver

The problem is that the two components are not talking about the same type of device.

 

Actually, that tells me something else very important:

hwdec_drmprime.c from mpv was written for decoders using: Vape, V4L2, other DRM backends

It creates AVHWDeviceType = DRM, instead, FFmpeg's hevc_rkmpp is a new decoder, which expects AVHWDeviceType = RKMPP. These two pieces of code were not made for each other.

 

That also explains why the decoder exists... I have hevc_rkmpp,  but mpv knows absolutely nothing about RKMPP. mpv only knows: drmprime and drmprime creates a DRM device.

 

My logical conclusion is that the official MPV is not suitable for the rkmpp hardware (it doesn't know about its existence). So what to do ? Where do I get a suitable MPV ? 

 

[Marus Gradinaru]

Oh, my GOD !   I used the Android14 OS image from FriendlyElec google drive, and every video format I tried worked perfectly with full hardware acceleration ! Using Kodi player, this NanoPi M5 it is even capable of playing H.265 Full-4K 60fps 10bit HDR, without frame drop ! So the hardware is perfectly functional for 4K movies. The problem is the software component that is present in other OSes besides Android.

Guys, I don't understand... Can't we take the drivers that FriendlyElec used in the Android14 OS image and adapt them for Armbian ? It would be brilliant to have an OS as cool as Armbian with full video acceleration capabilities !   Since I have this board, I'll gladly help you with any tests needed to make this Armbian for NanoPi M5 functional ! Just give me some ideas on what I should do... I will be your NanoPi M5 beta-testeer.

[Marus Gradinaru]

Hmm... that's strange. Does no one really want to participate in this discussion ? Has any of you really never used the NanoPi M5 before ? Don't you want us to join forces and work together to make this SBC run great ? It is a great piece of hardware who deserves a software to match. Let's show the world that there is a community for other SBCs besides Raspberry Pi !

 

So far we know for sure that the NanoPi M5 hardware is capable of full 4K. It is already working in Android14 OS. We just need to move the video drivers and software library froma Android to Armbian.

[tparys]

There's nearly 400 boards in the Armbian build system. There are not nearly that many people actively supporting those configurations, so not all are seeing the level of care and attention to detail that we'd all like to see.

 

There are other threads of folks discussing Rockchip hardware acceleration, which seems relatively new. You may need a more recent kernel (7.x mainline), and/or other bleeding edge software which is not part of the Ubuntu 26 baseline.

[Marus Gradinaru]

Ok, then. But at least remove that "It works out of the box" statement (which is not true), so that other people don't waste their time, like I did. This Armbian OS, at this time, does not support the NanoPi M5 board.

[JFL]

Hi @Marus Gradinaru, May be this might interest you.

 

Edited 1 hour ago by JFL

[eselarm]

If you use and Armbian image with kernel '6.1.115-vendor-rk35xx' (note there are many builds over time, all same name, but you need to look in config-6.1.115-vendor-rk35xx and maybe also consider the gcc compiler version to have RKMPP based method working. I mean the API is there, you need a special ffmpeg (from jellyfin for example to use it) in order to use RKMPP based decoding and encoding in HW. That is just CLI, server use-case, works on RK3568 and RK3588. RK3576 should have the same speed/ASIC blocks as RK3588 AFAIK, but check yourself. It can do 5x realtime speed 1080p50 HEVC to H264.

 

mpv 'uses open and agreed standards' and RKMPP is not. Also Android is completely different. Same is Windows or Apple iOS. Those are implemented by commercial/paid developers.

In fact it is worse, ffmpeg open-source developers have concluded already long time ago the Rockchip downstream kernel code was copied and violates licenses. (Rockchip copied code and put their names in it.). So since a few months, ffmpeg developers requested github to remove access and that happened. So following GPL licensing, that 6.1.115 kernel is essentially illegal. How you want to deal with that is up to you. It is like it is.

Anyway, 6.1.x downstream is getting old and might contain several unpatched security holes. So over time the 'problem' will solve itself as people won't trust it anymore despite being able to use every HW block in RK35xx. As already said, decoding generally is implemented as part on mainline kernel, you just need matching latest userspace. Encoding is much more complex. If you want that, only Intel/AMD is more or less viable option. Like N100, so in cheap miniPCs, certainly considering high RAM prices, is just a way better option. Plays all HW accelerated in FireFox (and mpv as well).  Does also VP9 encoding for example, is a royalty free codec, so you won't see this 2 decades old patents issues for H264 and HEVC. Also note AV1 HW decoding was the first to be available in mainline kernel for RK3588. There is just not much content I think. And HW AV1 encoding is another level of new silicon, is not really an option to do in software.