From: Jianfeng Liu <liujianfeng1994@gmail.com>
To: nicolas.dufresne@collabora.com
Cc: andy.yan@rock-chips.com, benjamin.gaignard@collabora.com,
boris.brezillon@collabora.com, conor+dt@kernel.org,
daniel.almeida@collabora.com, detlev.casanova@collabora.com,
devicetree@vger.kernel.org, didi.debian@cknow.org,
dsimic@manjaro.org, ezequiel@vanguardiasur.com.ar,
gregkh@linuxfoundation.org, heiko@sntech.de,
hverkuil-cisco@xs4all.nl, jonas@kwiboo.se, knaerzche@gmail.com,
krzk+dt@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
linux-rockchip@lists.infradead.org,
linux-staging@lists.linux.dev, liujianfeng1994@gmail.com,
mchehab@kernel.org, paul.kocialkowski@bootlin.com,
robh@kernel.org, sebastian.reichel@collabora.com
Subject: Re: [PATCH v2 2/4] media: rockchip: Introduce the rkvdec2 driver
Date: Fri, 21 Jun 2024 01:38:30 +0800 [thread overview]
Message-ID: <20240620173830.277022-1-liujianfeng1994@gmail.com> (raw)
In-Reply-To: <2349746d488f4edf9c7c40df5e15ff70d3ec67b7.camel@collabora.com>
Hi Detlev,
On Thu, 20 Jun 2024 10:07:41 -0400, Detlev Casanova wrote:
>This feels like hacking the driver to please a specific userspace application,
>so I'd like to understand better what chromium is doing.
Yes that hack is ugly. I have added log print in chromium to see if they
have set frame_mbs_only_flag to zero and found nothing. This sps->flags is
initialized 0 by kernel's v4l2 code. I printed all sps values in function
rkvdec2_h264_validate_sps and they are all initial values when chromiumn
call VIDIOC_STREAMON at the first time.
Hi Nicolas,
On Thu, 20 Jun 2024 11:03:54 -0400, Nicolas Dufresne wrote:
>This falls short of a specification to support the uninitialized usage by
>Chromium. That being said, we do make an effort to try and have a valid default
>SPS control and OUTPUT format combination. So my suggestion would be to set
>V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY in the default compound control init. This
>way, 0x0 get translate to 16x16 instead of 16x32, thus will work with more
>drivers.
Yeah that's the root cause. Vaule of sps->flags is initialized to 0 along
with pic_width_in_mbs_minus1 and pic_height_in_map_units_minus1, so this
check would fall with minimal decoder size 16x16.
>Chromium these days is not being tested on anything else then MTK, which has a
>64x64 minimum size, this is why they never get into this issue. This driver
>validation is entirely correct. Removing in some cases is unsafe, it would need
>to be replaced with STREAMON only validation of the CAPTURE sizes (which
>currently is validate by implied propagation of valid SPS/OUTPUT).
>
>**not even compiled tested, just to illustrate**
>
>diff --git a/drivers/media/v4l2-core/v4l2-ctrls-core.c b/drivers/media/v4l2-
>core/v4l2-ctrls-core.c
>index c4d995f32191..a55e165ea9c3 100644
>--- a/drivers/media/v4l2-core/v4l2-ctrls-core.c
>+++ b/drivers/media/v4l2-core/v4l2-ctrls-core.c
>@@ -111,6 +111,7 @@ static void std_init_compound(const struct v4l2_ctrl *ctrl,
>u32 idx,
> struct v4l2_ctrl_vp9_frame *p_vp9_frame;
> struct v4l2_ctrl_fwht_params *p_fwht_params;
> struct v4l2_ctrl_h264_scaling_matrix *p_h264_scaling_matrix;
>+ struct v4l2_ctrl_h264_sps *p_h264_sps;
> struct v4l2_ctrl_av1_sequence *p_av1_sequence;
> void *p = ptr.p + idx * ctrl->elem_size;
>
>@@ -179,6 +180,18 @@ static void std_init_compound(const struct v4l2_ctrl *ctrl,
>u32 idx,
> */
> memset(p_h264_scaling_matrix, 16,
>sizeof(*p_h264_scaling_matrix));
> break;
>+ case V4L2_CTRL_TYPE_H264_SPS:
>+ p_h264_sps = p;
>+ /*
>+ * Without V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY,
>+ * frame_mbs_only_flag set to 0 will translate to a miniumum
>+ * height of 32 (see H.264 specification 7-8). Some driver may
>+ * have a minimum size lower then 32, which would fail
>+ * validation with the SPS value. Set this flag, so that there
>+ * is now doubling in the height, allowing a valid default.
>+ */
>+ p_h264_sps->flags = V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY;
>+ break;
> }
> }
>
>Nicolas
This patch makes sense and I just confirmed that it works with chromium.
Thank you very much!
Best regards,
Jianfeng
next prev parent reply other threads:[~2024-06-20 17:38 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-19 14:57 [PATCH v2 0/4] media: rockchip: Add rkvdec2 driver Detlev Casanova
2024-06-19 14:57 ` [PATCH v2 1/4] media: rockchip: Move H264 CABAC table to header file Detlev Casanova
2024-06-19 14:57 ` [PATCH v2 2/4] media: rockchip: Introduce the rkvdec2 driver Detlev Casanova
2024-06-19 17:46 ` Jianfeng Liu
2024-06-20 14:07 ` Detlev Casanova
2024-06-20 15:03 ` Nicolas Dufresne
2024-06-20 17:38 ` Jianfeng Liu [this message]
2024-06-20 10:30 ` Krzysztof Kozlowski
2024-06-20 13:41 ` Sebastian Reichel
2024-06-21 6:10 ` Krzysztof Kozlowski
2024-06-19 14:57 ` [PATCH v2 3/4] media: dt-bindings: rockchip: Document RK3588 Video Decoder bindings Detlev Casanova
2024-06-19 17:37 ` Conor Dooley
2024-06-19 14:57 ` [PATCH v2 4/4] arm64: dts: rockchip: Add rkvdec2 Video Decoder on rk3588(s) Detlev Casanova
2024-06-19 15:28 ` Jonas Karlman
2024-06-19 17:19 ` Alex Bee
2024-06-19 18:06 ` Jonas Karlman
2024-06-20 13:31 ` Detlev Casanova
2024-06-24 9:16 ` Jonas Karlman
2024-06-27 20:56 ` Detlev Casanova
2024-06-27 22:39 ` Jonas Karlman
2024-06-28 13:31 ` Detlev Casanova
2024-07-26 15:26 ` Detlev Casanova
2024-07-26 19:55 ` Jonas Karlman
2024-06-19 15:34 ` Heiko Stübner
2024-06-20 10:24 ` Krzysztof Kozlowski
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=20240620173830.277022-1-liujianfeng1994@gmail.com \
--to=liujianfeng1994@gmail.com \
--cc=andy.yan@rock-chips.com \
--cc=benjamin.gaignard@collabora.com \
--cc=boris.brezillon@collabora.com \
--cc=conor+dt@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=detlev.casanova@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=didi.debian@cknow.org \
--cc=dsimic@manjaro.org \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=gregkh@linuxfoundation.org \
--cc=heiko@sntech.de \
--cc=hverkuil-cisco@xs4all.nl \
--cc=jonas@kwiboo.se \
--cc=knaerzche@gmail.com \
--cc=krzk+dt@kernel.org \
--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=linux-staging@lists.linux.dev \
--cc=mchehab@kernel.org \
--cc=nicolas.dufresne@collabora.com \
--cc=paul.kocialkowski@bootlin.com \
--cc=robh@kernel.org \
--cc=sebastian.reichel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).