Message-Id: <DFRU6ODDM71P.3NQGLRK8IVDUY@cknow-tech.com>
Date: Sun, 18 Jan 2026 16:56:41 +0100
From: "Diederik de Haas" <diederik@...ow-tech.com>
To: "Christian Hewitt" <christianshewitt@...il.com>, "Detlev Casanova"
 <detlev.casanova@...labora.com>, "Mauro Carvalho Chehab"
 <mchehab@...nel.org>, "Rob Herring" <robh@...nel.org>, "Krzysztof
 Kozlowski" <krzk+dt@...nel.org>, "Conor Dooley" <conor+dt@...nel.org>,
 "Heiko Stuebner" <heiko@...ech.de>
Cc: Olivier Crête <olivier.crete@...labora.com>, "Ezequiel
 Garcia" <ezequiel@...guardiasur.com.ar>, "Diederik de Haas"
 <diederik@...ow-tech.com>, "Dmitry Osipenko"
 <dmitry.osipenko@...labora.com>, "Thomas Gleixner" <tglx@...utronix.de>,
 "Dragan Simic" <dsimic@...jaro.org>, "Chukun Pan" <amadeus@....edu.cn>,
 "Andy Yan" <andyshrk@....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>
Subject: Re: [PATCH v3 0/3] media: rockchip: rkvdec: add support for the
 VDPU346 variant

Hi Christian,

On Sat Jan 10, 2026 at 6:37 AM CET, Christian Hewitt wrote:
> This series depends upon Detlev Casanova's current v8 series for VDPU381 and
> VDPU383 support [0]. It adds support for the VDPU346 IP block used for H264,
> HEVC and (in active work) VP9 on the RK356X boards. VDPU346 appears to be a
> close relation to VDPU381 used with RK3588, except with a single core, output
> limited to 4K, and minor feature differences, e.g. HEVC level 5.1 on VDPU346
> vs 6.1 on VDPU381. To handle differences we declare a new compatible.
> ...
> NB: Testing with the v1 series showed lower mbps bitrate performance. This
> appears to be resolved though it's unclear to me whether this results from
> kernel changes or the ongoing reworking of ffmpeg v4l2_request support [2].
> However with my current Linux 6.19-rc4 test branch [3] I'm now able to play
> Jellyfish H264 and HEVC test media over 100mbps.

I've now done quite a bit of testing on 3 separate devices: TL;DR:

Tested-by: Diederik de Haas <diederik@...ow-tech.com>  # PineTab2, Quartz64-A, NanoPi R5S

My main test setup was with Sway and mpv, which was based on a
self-compiled ffmpeg from [2] (commit: ea34873176, [4]) and mpv PR 14690
[5] (commit: 307d2a8 [6]).
That all ran on a Debian Forky system with my own 6.19-rc5 kernel ([7]).
Detlev's v8 series made things quite a bit better vs previous versions.

I also did a quick test with that same mpv and kernel, but then on KDE
Plasma and only on the PineTab2.

Finally, I did some tests with custom LibreELEC builds [8], which also
uses the code from this patch set.

While using the ``--vo=dmabuf-wayland`` parameter with mpv wasn't needed
on Rock 5B (RK3588) with most of my test files, it was absolutely needed
for all my test files on RK3566/RK3568.

Playing 1080p (or lower) media was either perfect or quite good, meaning
sometimes little artifacts were visible. This was on the PineTab2's
(RK3566) own screen or on my 1080p monitor with the Q64-A (RK3566) or
the NanoPi R5S (RK3568). Using the 'i'/'I' keyboard shortcut to display
an overlay with display statistics or enabling subtitles was generally a
'way' to get more artifacts. With 'i'/'I' you'd then also see the frame
drop count rise.
This was the case with both H264 and HEVC files, where I got the
'feeling' that HEVC worked (just) a bit better. Dunno if that's because
of the codec or that the video bitrate is lower with HEVC. Quite a few
of my test files are in both H264 as HEVC.

Testing with the 'Jellyfin' files was generally perfect. The maximum
bitrate I have is 30M though. There were some artifacts visible on the
PineTab2 though. With Jellyfin's HEVC files, but not my own HEVC files,
I did see the following warnings in dmesg:

  rkvdec_hevc_run: 291 callbacks suppressed
  rkvdec fdf80200.video-codec: Long an short term RPS not set

But I think that's expected? (given Detlev's remark on v8 cover page)

Playing 4K media on a 1080p (or lower) screen resulted in severe audio
sync issues. It seems the video rendering actually works, but in 'slow
motion'. Hearing 2 secs of audio for 1 sec of video was not uncommon.
Even with 4K media files, the CPU utilization was still around 15-25% on
all cores.

When testing on KDE Plasma, the display results were quite a bit worse.
I primarily mention this as I suspect that the 'display pipeline'
(possibly not the correct technical term), plays an (important) factor.
CPU utilization often around 40% on all cores.

I then connected the Q64-A or NanoPi R5S to my 4K TV. Displaying 1080
media was generally 'reasonable', meaning artifacts were visible several
times during playback. 4K media files still had severe 'audio sync'
issues.

I then went on to try LibreELEC's builds. The artifacts I (sometimes)
saw, were gone :-D OTOH, I did get several major issues 'in return',
like rk_iommu Page fault resulting in a black screen and the only way to
'recover' from it, was a reboot. I also got a kernel oops.
Some dmesg logs available at [9].

Then I tried something ... for 'shits and giggles'.
I recently learned about a Costa Rica 'test video' in 4K HDR (YT ID:
``LXb3EKWsInQ``) and I converted that to H264 and HEVC. The H264 version
was identified by MediaInfo as 'High 10@L6' and the HEVC version as
'Main 10@...1@...n'.
I tried to play that on the Q64-A (RK3566) ... and saw my TV show a
'popup' indicating it recognized it as HDR :-O And it actually played
them. It seems it couldn't completely keep up as it seems too slow at
some points and then appear to make a 'jump' to the then current time
spot. I think it worked a bit better with the HEVC version then the H264
one. But proper viewing/testing was always interrupted by a rk_iommu
Page fault and thus a black screen.
It worked even better on the NanoPi R5S (RK3568) and may even have
played it correctly; otherwise it came *really* close. But here too, the
fun was interrrupted by a black screen at some point.

So it seems it may be able to play video files/formats which, according
to the TRM, it isn't supposed to be able to play?
Too early to tell, but seeing the 'HDR popup' was a really cool surprise.

So, it's not perfect and I suspect various elements in the 'display
pipeline' can/should/need to be improved. I have no idea which though.
But the current state is good enough for me to give my Tested-by tag.

HTH,
  Diederik

> [0] https://patchwork.kernel.org/project/linux-rockchip/list/?series=1040540
> [1] https://github.com/rockchip-linux/kernel/blob/develop-6.6/arch/arm64/boot/dts/rockchip/rk356x.dtsi#L1539
> [2] https://code.ffmpeg.org/Kwiboo/FFmpeg/commits/branch/v4l2request-v3
> [3] https://github.com/chewitt/linux/commits/rockchip-6.19.y

[4] https://salsa.debian.org/diederik/ffmpeg/-/tree/v4l2request-v3-n8.1
[5] https://github.com/mpv-player/mpv/pull/14690
[6] https://salsa.debian.org/diederik/mpv/-/tree/v4l2request-support
[7] https://salsa.debian.org/diederik/linux/-/tree/cknow/master-next
[8] https://chewitt.libreelec.tv/testing/
[9] https://paste.sr.ht/~diederik/1d9468cbc52c49ec210b4b29754486608a9efea2
    https://paste.sr.ht/~diederik/214eb00f6ac634d16f54f25b2ec578ca27dc5134
    https://paste.sr.ht/~diederik/669c3731a108f650f9e0bdc03df848a69355d56f

> Christian Hewitt (3):
>   media: dt-bindings: rockchip: Add RK3568 Video Decoder bindings
>   media: rkvdec: Add support for the VDPU346 variant
>   arm64: dts: rockchip: Add the vdpu346 Video Decoders on RK356X
>
>  .../bindings/media/rockchip,vdec.yaml         |   2 +
>  arch/arm64/boot/dts/rockchip/rk356x-base.dtsi |  49 +++++++++
>  .../media/platform/rockchip/rkvdec/rkvdec.c   | 103 ++++++++++++++++++
>  3 files changed, 154 insertions(+)

Powered by blists - more mailing lists