In case someone is looking for ffmpeg support, been trying many combos to run my qt app with hardware decoding for videos. Here are my findings

 

Vendor kernel (Armbian 26.x)

 

This one seems to work quite differently than the version from a year ago.

- Hardware decoding is now by default through panthor (used to be rkmpp). Panthor module is loaded automatically in the kernel mods.

- I had to install the panthor-gpu overlay to get ffmpeg with hardware acceleration working

- I used Jellyfin ffmpeg but since it is not rkmpp, the default one is possibly good enough

- I had to adjust few device permissions

- No need anymore for any of the custom rkmpp or libmali repos, panthor seems to be able to deliver all the necessary GPU accel

 

KERNEL=="mpp_service", GROUP="video", MODE="0660"
KERNEL=="rga", GROUP="video", MODE="0660"
KERNEL=="rkvdec*", GROUP="video", MODE="0660"
KERNEL=="vepu*", GROUP="video", MODE="0660"

 

Results

- All my youtube downloaded videos (h264, h265, av1) are flawlessly playing

- Browser wgl acceleration is not working inside my QT web app. Not sure how the default chromium work but in older releases, armbian shipped a custom chromium.

- Vendor kernel is causing some wifi issues

 

Mainstream kernel 7.x (and probably 6.x)

 

- v4l2 seems to be the main driver

- there is a pipeline that works out of the box with hardware decoding and ffmpeg

- there is ffmpeg with patches for v4l2requests but the results seem similar with out-of-the-box

 

Results

- h264, h265 are playing out of the box without customizing ffmpeg

- 10 bit AV1 are not working even with most recent 7.2 kernel. Looks like NV15 is missing from current kernel for AV1. I assume collabora did implement this but I can't figure out in their matrix where this one sits.

- Browser wgl works out of the box inside QT web app

- Wifi is flawless

Edited October 13Oct 13 by OttawaHacker

Your split between the vendor and mainline paths matches what we see on RK3588 in production, and the AV1 gap is real: 10-bit AV1 needs NV15 and it isn't there yet, so on a mainline kernel the only honest options are falling back to 8-bit or staying on the vendor stack for that format. Worth saying out loud in your app's capability detection rather than letting it fail at runtime.
On the vendor side, two things that bite in deployed units rather than on the bench. First, CMA: the default allocation is fine for one stream and falls over somewhere around the third concurrent 4K decode. We ship with cma=256M on anything doing multi-stream and it removes a whole class of allocation failures that otherwise look like driver bugs. Second, if you're using VA-API rather than talking to MPP directly, the driver name has to be set explicitly or you silently get software decode and wonder why the CPU is pegged.
Your udev rules are the right ones. One addition that saves time later — put mpp_service and rga in the same group as your app user, not just video, because a service started before the session gets its groups from a different place than an interactive login, and you end up with permissions that work when you test and fail under systemd.
The WiFi difference you noticed between branches is worth its own thread if you have time to bisect it.