Message-Id: <3786B8EA-9796-40A9-8EEF-16CFAEE27766@gmail.com>
Date: Tue, 12 Aug 2025 09:20:51 +0200
From: Piotr Oniszczuk <piotr.oniszczuk@...il.com>
To: Detlev Casanova <detlev.casanova@...labora.com>
Cc: linux-kernel@...r.kernel.org,
 Mauro Carvalho Chehab <mchehab@...nel.org>,
 Heiko Stuebner <heiko@...ech.de>,
 linux-media@...r.kernel.org,
 linux-rockchip@...ts.infradead.org,
 linux-arm-kernel@...ts.infradead.org,
 kernel@...labora.com
Subject: Re: [PATCH v2 00/12] media: rkvdec: Add support for VDPU381 and
 VDPU383



> Wiadomość napisana przez Detlev Casanova <detlev.casanova@...labora.com> w dniu 8 sie 2025, o godz. 22:03:
> 
> These variants are found respectively in the RK3588 and RK3576 SoCs.
> This patch only adds support for H264 and H265 in both variants.
> 
> As there is a considerable part of the code that can be shared with the
> already supported rkvdec decoder driver, the support for these variants
> is added here rather than writing a new driver.
> 
> This patch set uses the newly introduced hevc_ext_sps_[ls]t_rps v4l2
> controls for HEVC [1].
> Therefore, a patched version of userpace tools is needed for HEVC
> support (added for GStreamer[2] and in an early stage for FFmpeg[3]).
> 
> This patch set also depends on the preparation patch set sent earlier [4]
> as well as the iommu restore fix [5] (already merged in linux-media) and
> Nicolas Frattaroli's bitmap patch [6] to support setting registers that
> uses upper 16 bits as masks.
> 
> [1]: https://lore.kernel.org/all/20250807194327.69900-1-detlev.casanova@collabora.com/
> [2]: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9355
> [3]: https://gitlab.collabora.com/detlev/ffmpeg
> [4]: https://lore.kernel.org/all/20250623160722.55938-1-detlev.casanova@collabora.com/
> [5]: https://lore.kernel.org/all/20250508-rkvdec-iommu-reset-v1-1-c46b6efa6e9b@collabora.com/
> [6]: https://lore.kernel.org/all/20250623-byeword-update-v2-1-cf1fc08a2e1f@collabora.com/
> 
> Changes since v1:
> - Add parsing of the short and long term ref frame sets from the new v4l2
>   controls
> - Add RPS cache to avoid parsing the same data again
> - Fix HEVC pixel formats selection
> - Fix multiple indentation errors
> 
> Detlev Casanova (12):
>  media: rkvdec: Switch to using structs instead of writel
>  media: rkvdec: Move cabac table to its own source file
>  media: rkvdec: Use structs to represent the HW RPS
>  media: rkvdec: Move h264 functions to common file
>  media: rkvdec: Add per variant configuration
>  media: rkvdec: Add RCB and SRAM support
>  media: rkvdec: Support per-variant interrupt handler
>  media: rkvdec: Enable all clocks without naming them
>  media: rkvdec: Add H264 support for the VDPU381 variant
>  media: rkvdec: Add H264 support for the VDPU383 variant
>  media: rkvdec: Add HEVC support for the VDPU381 variant
>  media: rkvdec: Add HEVC support for the VDPU383 variant
> 
> ..

Detlev,

I give run for this series on rk3576 and rk3588 devices (various SBC boards) on mainline 6.16 kernel.
Userspace was: KODI, MythTV and mpv.
All are using ffmpeg - but without [3] applied*.
Tested video rendering pipelines was: EGL DAMBuf and DRM direct to plane

Happy to report:
-all h264 content** i tested was decoded ok.
-on some rk3576 h264 rendering manifest known "green lines" issue***  
-hevc content**** was also decoded ok except samples requiring long sps/rps hinting from userspace (from ffmpeg in my case)


* - it looks (to me) your's ffmpeg branch changes are incompatible with yours rkvdec code (i.e. ffmpeg refers to V4L2_HEVC_EXT_SPS_RPS_FLAG_INTER_REF_PIC_SET_PRED but kernel v2 driver don't have it)

**  - i'm referring to multiple h.264 movies and TV HD channels

*** - issue of thin green lines we discussed on rockchip IRC channel

**** - as my ffmpeg7.1 has not applied newly introduced hevc_ext_sps_[ls]t_rps v4l2
controls for HEVC (due *) - some content is not decoded properly.

If any extra tests can be helpful - i'' be more that happy to do so!

br 

Powered by blists - more mailing lists