Message-Id: <DCRR9XY9MT2L.3JSK4SYGMT57R@cknow.org>
Date: Sat, 13 Sep 2025 16:51:59 +0200
From: "Diederik de Haas" <didi.debian@...ow.org>
To: "Jonas Karlman" <jonas@...boo.se>, "Ezequiel Garcia"
 <ezequiel@...guardiasur.com.ar>, "Detlev Casanova"
 <detlev.casanova@...labora.com>, "Mauro Carvalho Chehab"
 <mchehab@...nel.org>
Cc: "Alex Bee" <knaerzche@...il.com>, "Nicolas Dufresne"
 <nicolas.dufresne@...labora.com>, <linux-media@...r.kernel.org>,
 <linux-rockchip@...ts.infradead.org>, <devicetree@...r.kernel.org>,
 <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
 "Christian Hewitt" <christianshewitt@...il.com>
Subject: Re: [PATCH v3 0/7] media: rkvdec: Add HEVC backend

On Fri Sep 5, 2025 at 6:19 PM CEST, Jonas Karlman wrote:
> This series add a HEVC backend to the Rockchip Video Decoder driver.

I did some testing and the TL;DR version is:

Tested-by: Diederik de Haas <didi.debian@...ow.org>  # Rock64, RockPro64, Quartz64-B, NanoPi R5S

Now for the long version ;-P

I built a 5.17-rc5 kernel with this patch set [1], which was based upon
linuxtv's next branch, so I just took all their commits on 2025-09-07.
Then rebased Detlev's rkvdec patch set on top of that.
As I have quite a few rk356x based devices and there wasn't a DT patch
to enable rkvdec2, I 'assembled' my own one. (And some more patches)

I have a patched ffmpeg [2] and with its -dev libraries built a patched
mpv [3]. Installed that onto (mostly) Debian Forky systems with mesa
25.2.2 and sway 1.11. I have a number of test files which are provided
via NFS so storage device wouldn't matter and it's also what I use with
LibreELEC (both 12.2 as 12.90.1 provided by 'chewitt').
And then I went on to perform the same tests on these devices:

1) Pine64 Rock64 (rk3328)
2) Pine64 RockPro64 (rk3399)
3) Pine64 Quartz64 Model B (rk3566) *
4) FriendlyELEC NanoPi R5S (rk3568) *

*) I blacklisted the hantro driver

My testing showed that the 'classical' Big Buck Bunny video worked the
best for testing ... meaning it caused the most 'problems'.
I used the 'Standard 2D' 'Full HD (1920x1080)' '60 fps' version which
you can download from [4]. That'll give you an 8-bit encoded x264
version of that video. I have converted that video to x265 with a script
I wrote (quite) a while ago [5]; instructions near the end of that
script (no hdr no resize 'branch' about $TENBIT_PARAMS).
That resulted in 2 test files:
a) bbb_sunflower_1080p_60fps_normal.x265.cf24.slow.8bit.mp4
b) bbb_sunflower_1080p_60fps_normal.x265.cf24.medium.10bit.mp4

Testing went as follows:
I logged into the device, started sway and opened a 'foot' terminal and
navigated to my NFS share with the test files. Then I used

  mpv --hwdec=v4l2request <video-file> [--fullscreen=yes]

Without the 'fullscreen' param it shows the video in the right part of
the screen (1080p monitor), while the left part shows mpv's output.
This made it easy to see 'dropped frames' and any audio delay.
I played each file twice, one using half the screen and one fullscreen.

This had less of an effect then I expected; only in a few cases it
'pushed it over the edge' and the only real effect was with Rock64 ...
which being the least powerful is (kinda) expected.

The results of the 10-bit x265 files was uniform: only a blue screen was
visible and OSD (with 'I' or 'O' in mpv) didn't work. Interestingly it
also had no frame drops ... except when doing 'I' (with no visible
effect), then it dropped a couple of frames (one time quite a few).
Mpv showed this error message each time:
[vo/gpu] Initializing texture for hardware decoding failed

For the 8-bit x265 file, the results were more varied:
- On Rock64 HW accel worked, but the videos had a red 'glare' over them.
  None of the other devices had that, so maybe related to 'lima'?
  On LE it did NOT have the red glare. It did seem to have quite a bit
  of trouble starting it
- On Rock64 it dropped 970 frames in 60 secs and 2480 in fullscreen.
  This resulted in quite a shockery display and noticeable artifacts.
  That was not (or at least a whole lot less) the case with LE.
- On the other devices there was not much difference in dropped frames
  when it came to windowed vs full-screen, but the frame drops were
  quite high ~2000 when HW accelerated and up to ~3000 when not
  I got the impression that ~3Mbps bitrate was a tipping point.
- The original BBB file (thus x264) had a similar high frame drop rate,
  so the problem seems unrelated to this patch set
- Audio delay was sometimes huge (>60 secs after 60 secs :-O), and HW
  acceleration fixed that (due to free 'CPU' capacity?)

The 'scores' for my other test files were actually quite good \o/
All my video were HW accelerated; 8-bit with nv12 worked good while
10-bit with nv15 was very blue. But all were corrected detected.

So IMO this is a massive improvement! Thanks a LOT :-D

Cheers,
  Diederik

[1] https://salsa.debian.org/diederik/linux/-/tree/cknow/media-next
(Salsa CI fails as it can't deal with the ~ in 6.17~rc5)
[2] https://salsa.debian.org/diederik/ffmpeg/-/tree/v4l2request-2025-v3-rkvdec-n7.1
[3] https://salsa.debian.org/diederik/mpv/-/tree/v4l2request-support
[4] http://bbb3d.renderfarming.net/download.html
[5] https://paste.sr.ht/~diederik/52b81ebc4c14b5146eb9b687bb1e8c1d62787991

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists