From: Piotr Oniszczuk <piotr.oniszczuk@gmail.com>
To: Detlev Casanova <detlev.casanova@collabora.com>
Cc: linux-kernel@vger.kernel.org,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Heiko Stuebner <heiko@sntech.de>,
linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, kernel@collabora.com
Subject: Re: [PATCH v2 00/12] media: rkvdec: Add support for VDPU381 and VDPU383
Date: Tue, 12 Aug 2025 09:20:51 +0200 [thread overview]
Message-ID: <3786B8EA-9796-40A9-8EEF-16CFAEE27766@gmail.com> (raw)
In-Reply-To: <20250808200340.156393-1-detlev.casanova@collabora.com>
> Wiadomość napisana przez Detlev Casanova <detlev.casanova@collabora.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
next prev parent reply other threads:[~2025-08-12 7:21 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-08 20:03 Detlev Casanova
2025-08-08 20:03 ` [PATCH v2 01/12] media: rkvdec: Switch to using structs instead of writel Detlev Casanova
2025-08-08 20:03 ` [PATCH v2 02/12] media: rkvdec: Move cabac table to its own source file Detlev Casanova
2025-08-08 20:03 ` [PATCH v2 03/12] media: rkvdec: Use structs to represent the HW RPS Detlev Casanova
2025-08-08 20:03 ` [PATCH v2 04/12] media: rkvdec: Move h264 functions to common file Detlev Casanova
2025-08-08 20:03 ` [PATCH v2 05/12] media: rkvdec: Add per variant configuration Detlev Casanova
2025-08-11 6:13 ` Krzysztof Kozlowski
2025-08-11 13:52 ` Detlev Casanova
2025-08-08 20:03 ` [PATCH v2 06/12] media: rkvdec: Add RCB and SRAM support Detlev Casanova
2025-08-11 6:13 ` Krzysztof Kozlowski
2025-08-11 13:54 ` Detlev Casanova
2025-08-11 14:01 ` Krzysztof Kozlowski
2025-08-11 18:44 ` Detlev Casanova
2025-08-08 20:03 ` [PATCH v2 07/12] media: rkvdec: Support per-variant interrupt handler Detlev Casanova
2025-08-08 20:03 ` [PATCH v2 08/12] media: rkvdec: Enable all clocks without naming them Detlev Casanova
2025-08-08 20:03 ` [PATCH v2 09/12] media: rkvdec: Add H264 support for the VDPU381 variant Detlev Casanova
2025-08-12 17:07 ` Dmitry Osipenko
2025-09-20 15:00 ` Diederik de Haas
2025-09-20 16:15 ` Jonas Karlman
2025-09-20 18:06 ` Diederik de Haas
2025-08-08 20:03 ` [PATCH v2 10/12] media: rkvdec: Add H264 support for the VDPU383 variant Detlev Casanova
2025-08-09 11:53 ` kernel test robot
2025-08-11 18:28 ` Nicolas Dufresne
2025-08-08 20:03 ` [PATCH v2 11/12] media: rkvdec: Add HEVC support for the VDPU381 variant Detlev Casanova
2025-08-09 13:17 ` kernel test robot
2025-09-20 15:07 ` Diederik de Haas
2025-09-20 16:23 ` Jonas Karlman
2025-09-22 14:19 ` Nicolas Dufresne
2025-09-29 12:47 ` Detlev Casanova
2025-08-08 20:03 ` [PATCH v2 12/12] media: rkvdec: Add HEVC support for the VDPU383 variant Detlev Casanova
2025-08-11 9:56 ` [PATCH v2 00/12] media: rkvdec: Add support for VDPU381 and VDPU383 Heiko Stübner
2025-08-11 16:33 ` Detlev Casanova
2025-08-12 7:20 ` Piotr Oniszczuk [this message]
2025-09-17 17:34 ` Diederik de Haas
2025-09-18 13:31 ` Nicolas Dufresne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3786B8EA-9796-40A9-8EEF-16CFAEE27766@gmail.com \
--to=piotr.oniszczuk@gmail.com \
--cc=detlev.casanova@collabora.com \
--cc=heiko@sntech.de \
--cc=kernel@collabora.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mchehab@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®