BPI-R2 Pro Ubuntu VPU Support Decode and Encode

Hi, Before ordering board, we want to know if ubuntu support VPU? Thanks.

Imho this is more linux kernel related than distribution. There are Patches for support,but i don’t know if they are applied

https://patchwork.kernel.org/project/linux-media/patch/[email protected]/

But you need to add nodes enabling them in bpi-r2pro dts and add driver. Have not done anything yet with it

1 Like

Yes, decoding support works in Armbian and Libreelec.

Were vpu patches merged to mainline (5.19)? Have you added anything to bpi-r2pro dts?

How to check if it works?

The way to check it is

It should be compiled, than there are binaries mpi_dec_test etc. and give it a try.

1 Like

In 5.19 there are changes for this, but not completely, I am adding some things in the form of temporary patches (until everything is included in the main code).

The easiest test is to start watching videos with different resolutions 720p 1080p 1440p. For example, in Armbian you will be able to watch this video in full-screen view. In Libreelec - you can press a key combination during playback and see details of which decoding mode is used by SW or HW. Please note that not all formats have full HW decoding yet. But even in SWR 2 pro mode, it normally copes with video up to 1440p.

This is the wrong way for the main core, there is no MPP in it, everything is implemented via v4l.

I looked into your source but found nothing vpu related.

Which mediaplayer is used from openelec? Is there a way to check via ffmpeg or similar? Dts patch mentions a ffmpeg way but link points to a Patch modifying ffmpeg source heavy much

Rockchip uses their own downstream kernel and mainline implementation is different. Current dts seems not needing enabling in bpi-r2pro dts as in dtsi nodes are not disabled

Actually it is the right way, This is what Rockchip engineer solutions. If you able to get decoded video it means you are using Hardware. We are able to play 16 stream with 480p at RK3568 Radxa 3A board.

LE uses its own version (with additional patches) of FFMPEG. In Armbian, I test via MPV without additional patches (which also uses FFMPEG), mpv and ffmpeg use default ones from network repositories.

yes, all the necessary changes are in the shared dtsi files.

No, this is the wrong way for the main core. There is no support for MPP in the main kernel, it is a specific code exclusively for the old BSP kernel. If you need an old BSP kernel, it is available for the Armbian version with the Legacy kernel, but you need to add all the other components and libraries (MPP etc) yourself.

Rockchip stopped support on FFMPEG for VPU.

We do not need old BSP Kernel.

We need Hardware Decode and Encode support.

Also, we need those on Ubuntu or Debian.

Any guide or help on this would be appreciated.

This is example for kernel 5.10 and mpp is supported.

You can check.

5.10 = BSP has nothing to do with the main core.

Tested on 5.18-main, confirmed - works.

Next drivers additionally required:



P.S. Additional v4l video player support might be required which is depends on distro.

P.P.S. Having troubles playing 4k videos, so need to make sure if HW decoding was actually used.

1 Like

added series + defconfig changes to 5.18-main tree, is this enough?

if yes i can add it to 5.19 and 6.0

For now I’m not sure if HW was actually used: 720p videos played smoothly with no frame drops, but 4k -not. As I understood for now mainline (+ patches) only supports hantro which is limited to 1080p, rkvdec2 (supports 4k) is not implemented.

But the CPU is likely enough to process 720p videos, so it might be a CPU decoding.

After loading hantro-vpu module i have:

[147814.541636] hantro_vpu: module is from the staging directory, the quality is unknown, you have been warned.
[147814.545292] hantro-vpu fdea0000.video-codec: registered rockchip,rk3568-vpu-dec as /dev/video0

Also i see device in interrupts:

bpi-r2pro / # cat /proc/interrupts | grep video
 29:          0          0          0          0     GICv3 171 Level     fdea0000.video-codec

But its count doesn’t raise on video playback. So for now it’s likely a CPU decoding.

Looks like this codec needs software support (GStreamer, etc)

I’m working on it, and I will post any updates here.

have added dts-changes and defconfig to this tree: https://github.com/frank-w/BPI-R2-4.14/commits/6.0-r2pro-multimedia

driver-changes were already there

Driver detects on 6.0-rc (i use both multimedia+pcie):

bpi-r2pro ~ # cat /proc/interrupts | grep video 29: 0 0 0 0 GICv3 171 Level fdea0000.video-codec

v4l2-compliance-out.txt (3.9 КБ)

1 Like

But all is “not supported” so it looks like something is missing