From: "Diederik de Haas" <didi.debian@cknow.org>
To: "Jonas Karlman" <jonas@kwiboo.se>
Cc: "Ezequiel Garcia" <ezequiel@vanguardiasur.com.ar>,
"Detlev Casanova" <detlev.casanova@collabora.com>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Alex Bee" <knaerzche@gmail.com>,
"Nicolas Dufresne" <nicolas.dufresne@collabora.com>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
"linux-rockchip@lists.infradead.org"
<linux-rockchip@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/7] media: rkvdec: Add HEVC backend
Date: Tue, 12 Aug 2025 20:28:43 +0200 [thread overview]
Message-ID: <DC0NUGDTCUYD.QT1BLJEGXYFG@cknow.org> (raw)
In-Reply-To: <64d551d7-924a-48af-96ca-224fa94543d8@kwiboo.se>
[-- Attachment #1: Type: text/plain, Size: 2933 bytes --]
Hi Jonas,
On Tue Aug 12, 2025 at 7:11 PM CEST, Jonas Karlman wrote:
> On 8/12/2025 2:11 PM, Diederik de Haas wrote:
>> On Sun Aug 10, 2025 at 11:24 PM CEST, Jonas Karlman wrote:
>>> This series add a HEVC backend to the Rockchip Video Decoder driver.
>>>
>>> With the dependent H.264 High 10 and 4:2:2 profile support series
>>> finally merged there is finally time to send a v2 with minor changes and
>>> a suggested code style fix of this series. v1 of this series has been
>>> fully functional up until recent unstaging of the rkvdec driver.
>>>
>>> Patch 1 add the new HEVC backend.
>>> Patch 2-3 add variants support to the driver.
>>> Patch 4 add support for a rk3288 variant.
>>> Patch 5 add a rk3328 variant to work around hw quirks.
>>> Patch 6-7 add device tree node for rk3288.
>>
>> It looks like I had a previous version of linuxtv-rkvdec-hevc-v2 branch
>> locally and that also had this commit:
>> - media: rkvdec: Keep decoder clocks gated
>>
>> Is that one no longer needed/useful/etc ?
>
> I do not think it is, could possible be to keep power consumption at
> minimum while decoding. Some parts enable auto gating and then we
> disable it when decoding is complete. With auto-suspend the entire block
> is disabled anyway so this probably did not make any noticeable
> difference and could instead introduce new possible issues.
Makes sense, thanks.
>> And 'chewitt' also had a commit to fix 8/10-bit selection:
>> https://github.com/chewitt/linux/commit/4b93b05d2ca608bc23f1d52bcc32df926d435c7c
>> "WIP: media: rkvdec: fix 8-bit/10-bit format selection"
>>
>> I haven't tried that one (yet), but did try an other variant with
>> changing the ordering in rkvdec_hevc_decoded_fmts but that didn't work
>> in my tests. (Can ofc be PEBKAC)
>
> The format selection in kernel for this series should be correct,
> however to ensure 10-bit works you need following for ffmpeg-v4l2request
> to select and use 10-bit pixel formats:
>
> libdrm 2.4.104+ (NV15) / 2.4.118+ (NV20)
> - 10-bit drm formats, ffmpeg v4l2request test with a #ifdef
>
> linux headers v6.16-rc1+ (NV15/NV20)
> - 10-bit v4l2 pix fmt, ffmpeg v4l2request test with a #ifdef
>
> FFmpeg v4l2request will not negotiate use of 10-bit formats without
> DRM_FORMAT_NV15/NV20 and V4L2_PIX_FMT_NV15/NV20 defined when ffmpeg was
> compiled.
>
> That would be the most likely issue if only 8-bit formats is working.
Thanks so much for the detailed explanation with which I can check where
my stack wasn't doing what I hoped it would :-)
>> Would that be useful? I do/did have consistent problems with playing
>> 10-bit encoded video files.
>
> Looking quickly at the 'fix 8/10-bit selection' commit the issue is that
> rkvdec_hevc_get_image_fmt() was incomplete to begin with. The
> rkvdec_hevc_get_image_fmt() in this series has been correct since v1.
Thanks :)
Cheers,
Diederik
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: "Diederik de Haas" <didi.debian@cknow.org>
To: "Jonas Karlman" <jonas@kwiboo.se>
Cc: "Ezequiel Garcia" <ezequiel@vanguardiasur.com.ar>,
"Detlev Casanova" <detlev.casanova@collabora.com>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Alex Bee" <knaerzche@gmail.com>,
"Nicolas Dufresne" <nicolas.dufresne@collabora.com>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
"linux-rockchip@lists.infradead.org"
<linux-rockchip@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/7] media: rkvdec: Add HEVC backend
Date: Tue, 12 Aug 2025 20:28:43 +0200 [thread overview]
Message-ID: <DC0NUGDTCUYD.QT1BLJEGXYFG@cknow.org> (raw)
In-Reply-To: <64d551d7-924a-48af-96ca-224fa94543d8@kwiboo.se>
[-- Attachment #1.1: Type: text/plain, Size: 2933 bytes --]
Hi Jonas,
On Tue Aug 12, 2025 at 7:11 PM CEST, Jonas Karlman wrote:
> On 8/12/2025 2:11 PM, Diederik de Haas wrote:
>> On Sun Aug 10, 2025 at 11:24 PM CEST, Jonas Karlman wrote:
>>> This series add a HEVC backend to the Rockchip Video Decoder driver.
>>>
>>> With the dependent H.264 High 10 and 4:2:2 profile support series
>>> finally merged there is finally time to send a v2 with minor changes and
>>> a suggested code style fix of this series. v1 of this series has been
>>> fully functional up until recent unstaging of the rkvdec driver.
>>>
>>> Patch 1 add the new HEVC backend.
>>> Patch 2-3 add variants support to the driver.
>>> Patch 4 add support for a rk3288 variant.
>>> Patch 5 add a rk3328 variant to work around hw quirks.
>>> Patch 6-7 add device tree node for rk3288.
>>
>> It looks like I had a previous version of linuxtv-rkvdec-hevc-v2 branch
>> locally and that also had this commit:
>> - media: rkvdec: Keep decoder clocks gated
>>
>> Is that one no longer needed/useful/etc ?
>
> I do not think it is, could possible be to keep power consumption at
> minimum while decoding. Some parts enable auto gating and then we
> disable it when decoding is complete. With auto-suspend the entire block
> is disabled anyway so this probably did not make any noticeable
> difference and could instead introduce new possible issues.
Makes sense, thanks.
>> And 'chewitt' also had a commit to fix 8/10-bit selection:
>> https://github.com/chewitt/linux/commit/4b93b05d2ca608bc23f1d52bcc32df926d435c7c
>> "WIP: media: rkvdec: fix 8-bit/10-bit format selection"
>>
>> I haven't tried that one (yet), but did try an other variant with
>> changing the ordering in rkvdec_hevc_decoded_fmts but that didn't work
>> in my tests. (Can ofc be PEBKAC)
>
> The format selection in kernel for this series should be correct,
> however to ensure 10-bit works you need following for ffmpeg-v4l2request
> to select and use 10-bit pixel formats:
>
> libdrm 2.4.104+ (NV15) / 2.4.118+ (NV20)
> - 10-bit drm formats, ffmpeg v4l2request test with a #ifdef
>
> linux headers v6.16-rc1+ (NV15/NV20)
> - 10-bit v4l2 pix fmt, ffmpeg v4l2request test with a #ifdef
>
> FFmpeg v4l2request will not negotiate use of 10-bit formats without
> DRM_FORMAT_NV15/NV20 and V4L2_PIX_FMT_NV15/NV20 defined when ffmpeg was
> compiled.
>
> That would be the most likely issue if only 8-bit formats is working.
Thanks so much for the detailed explanation with which I can check where
my stack wasn't doing what I hoped it would :-)
>> Would that be useful? I do/did have consistent problems with playing
>> 10-bit encoded video files.
>
> Looking quickly at the 'fix 8/10-bit selection' commit the issue is that
> rkvdec_hevc_get_image_fmt() was incomplete to begin with. The
> rkvdec_hevc_get_image_fmt() in this series has been correct since v1.
Thanks :)
Cheers,
Diederik
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-08-12 20:33 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-10 21:24 [PATCH v2 0/7] media: rkvdec: Add HEVC backend Jonas Karlman
2025-08-10 21:24 ` Jonas Karlman
2025-08-10 21:24 ` [PATCH v2 1/7] " Jonas Karlman
2025-08-10 21:24 ` Jonas Karlman
2025-08-11 19:12 ` Nicolas Dufresne
2025-08-11 19:12 ` Nicolas Dufresne
2025-08-11 19:46 ` Jonas Karlman
2025-08-11 19:46 ` Jonas Karlman
2025-08-11 20:27 ` Nicolas Dufresne
2025-08-11 20:27 ` Nicolas Dufresne
2025-08-11 21:07 ` Nicolas Dufresne
2025-08-11 21:07 ` Nicolas Dufresne
2025-08-12 0:58 ` Jonas Karlman
2025-08-12 0:58 ` Jonas Karlman
2025-08-12 13:07 ` Nicolas Dufresne
2025-08-12 13:07 ` Nicolas Dufresne
2025-08-12 19:54 ` Detlev Casanova
2025-08-12 19:54 ` Detlev Casanova
2025-08-17 16:39 ` Jonas Karlman
2025-08-17 16:39 ` Jonas Karlman
2025-08-18 8:25 ` Detlev Casanova
2025-08-18 8:25 ` Detlev Casanova
2025-08-12 20:10 ` Detlev Casanova
2025-08-12 20:10 ` Detlev Casanova
2025-08-17 16:46 ` Jonas Karlman
2025-08-17 16:46 ` Jonas Karlman
2025-08-29 20:22 ` Nicolas Dufresne
2025-08-29 20:22 ` Nicolas Dufresne
2025-09-03 7:28 ` Jonas Karlman
2025-09-03 7:28 ` Jonas Karlman
2025-09-03 13:44 ` Nicolas Dufresne
2025-09-03 13:44 ` Nicolas Dufresne
2025-08-10 21:24 ` [PATCH v2 2/7] media: rkvdec: Add variants support Jonas Karlman
2025-08-10 21:24 ` Jonas Karlman
2025-08-11 21:11 ` Nicolas Dufresne
2025-08-11 21:11 ` Nicolas Dufresne
2025-08-10 21:24 ` [PATCH v2 3/7] media: rkvdec: Implement capability filtering Jonas Karlman
2025-08-10 21:24 ` Jonas Karlman
2025-08-11 21:17 ` Nicolas Dufresne
2025-08-11 21:17 ` Nicolas Dufresne
2025-08-10 21:24 ` [PATCH v2 4/7] media: rkvdec: Add RK3288 variant Jonas Karlman
2025-08-10 21:24 ` Jonas Karlman
2025-08-11 21:17 ` Nicolas Dufresne
2025-08-11 21:17 ` Nicolas Dufresne
2025-08-10 21:24 ` [PATCH v2 5/7] media: rkvdec: Disable QoS for HEVC and VP9 on RK3328 Jonas Karlman
2025-08-10 21:24 ` Jonas Karlman
2025-08-11 21:25 ` Nicolas Dufresne
2025-08-11 21:25 ` Nicolas Dufresne
2025-08-11 22:22 ` Jonas Karlman
2025-08-11 22:22 ` Jonas Karlman
2025-08-12 12:47 ` Nicolas Dufresne
2025-08-12 12:47 ` Nicolas Dufresne
2025-08-11 23:08 ` Jonas Karlman
2025-08-11 23:08 ` Jonas Karlman
2025-08-12 13:00 ` Nicolas Dufresne
2025-08-12 13:00 ` Nicolas Dufresne
2025-08-17 16:18 ` Jonas Karlman
2025-08-17 16:18 ` Jonas Karlman
2025-08-10 21:24 ` [PATCH v2 6/7] media: dt-bindings: rockchip,vdec: Add RK3288 compatible Jonas Karlman
2025-08-10 21:24 ` Jonas Karlman
2025-08-10 21:24 ` [PATCH v2 7/7] ARM: dts: rockchip: Add vdec node for RK3288 Jonas Karlman
2025-08-10 21:24 ` Jonas Karlman
2025-08-11 21:52 ` [PATCH v2 0/7] media: rkvdec: Add HEVC backend Nicolas Dufresne
2025-08-11 21:52 ` Nicolas Dufresne
2025-08-12 0:00 ` Jonas Karlman
2025-08-12 0:00 ` Jonas Karlman
2025-08-12 12:38 ` Nicolas Dufresne
2025-08-12 12:38 ` Nicolas Dufresne
2025-08-12 12:44 ` Nicolas Dufresne
2025-08-12 12:44 ` Nicolas Dufresne
2025-08-12 17:31 ` Jonas Karlman
2025-08-12 17:31 ` Jonas Karlman
2025-08-12 18:26 ` Nicolas Dufresne
2025-08-12 18:26 ` Nicolas Dufresne
2025-08-12 18:52 ` Nicolas Dufresne
2025-08-12 18:52 ` Nicolas Dufresne
2025-08-17 16:33 ` Jonas Karlman
2025-08-17 16:33 ` Jonas Karlman
2025-08-12 19:57 ` Detlev Casanova
2025-08-12 19:57 ` Detlev Casanova
2025-08-12 21:11 ` Nicolas Dufresne
2025-08-12 21:11 ` Nicolas Dufresne
2025-08-12 12:11 ` Diederik de Haas
2025-08-12 12:11 ` Diederik de Haas
2025-08-12 12:55 ` Diederik de Haas
2025-08-12 12:55 ` Diederik de Haas
2025-08-12 13:27 ` Nicolas Dufresne
2025-08-12 13:27 ` Nicolas Dufresne
2025-08-12 14:09 ` Diederik de Haas
2025-08-12 14:09 ` Diederik de Haas
2025-08-14 21:25 ` Alex Bee
2025-08-14 21:25 ` Alex Bee
2025-08-12 17:11 ` Jonas Karlman
2025-08-12 17:11 ` Jonas Karlman
2025-08-12 18:28 ` Diederik de Haas [this message]
2025-08-12 18:28 ` Diederik de Haas
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=DC0NUGDTCUYD.QT1BLJEGXYFG@cknow.org \
--to=didi.debian@cknow.org \
--cc=detlev.casanova@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=jonas@kwiboo.se \
--cc=knaerzche@gmail.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 \
--cc=nicolas.dufresne@collabora.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.