linux-kernel - Re: [PATCH 1/3] media: rockchip: Introduce the rkvdec2 driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Wed, 19 Jun 2024 15:41:50 +0800
From: Jianfeng Liu <liujianfeng1994@...il.com>
To: nicolas@...fresne.ca
Cc: alchark@...il.com,
	andy.yan@...k-chips.com,
	conor+dt@...nel.org,
	cristian.ciocaltea@...labora.com,
	detlev.casanova@...labora.com,
	devicetree@...r.kernel.org,
	didi.debian@...ow.org,
	dsimic@...jaro.org,
	gregkh@...uxfoundation.org,
	heiko@...ech.de,
	krzk+dt@...nel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org,
	linux-rockchip@...ts.infradead.org,
	linux-staging@...ts.linux.dev,
	liujianfeng1994@...il.com,
	mchehab@...nel.org,
	robh@...nel.org,
	sebastian.reichel@...labora.com
Subject: Re: [PATCH 1/3] media: rockchip: Introduce the rkvdec2 driver

Hi,

On Tue, 18 Jun 2024 08:39:07 -0400, Detlev Casanova wrote:
>> I think the min/max width/height are incorrect. From rockchip's TRM V1.0
>> Part1 page 374, supported image size is 64x64 to 65472x65472.
>
>Page 374 shows the sizes for h265. h264 is the next table, where 16x16 and 
>65520x65520 is documented.
>
>> And my
>> chromium can't use rkvdec2 because min width/height are set to 16, which
>> 
>> will cause error at here in rkvdec2_h264_validate_sps:
>> >+	if (width > ctx->coded_fmt.fmt.pix_mp.width ||
>> >+	    height > ctx->coded_fmt.fmt.pix_mp.height)
>> >+		return -EINVAL;
>> 
>> width is 16, height is 32 while ctx->coded_fmt.fmt.pix_mp.width and
>> ctx->coded_fmt.fmt.pix_mp.height are both 16.
>
>Maybe
>
>if (!(sps->flags & V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY))
>	height *= 2;
>
>is causing issues in this case, I can check.

You are right. H264 decoder should support 16x16 to 65520x65520. After 
removeing the "height *= 2" code chromium can also decode video now.
Checking with V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY is copied from rkvdec and
rkvdec has min width/height 48x48 so there is no issue with chromium.
Chromium will call VIDIOC_STREAMON with size 16x16 and without sps flag
V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY at the beginning of the video play.
Gstreamer doesn't has this issue because it will call VIDIOC_STREAMON
with the actual video size like 1920x1080.

On Tue, 18 Jun 2024 12:34:07 -0400, Nicolas Dufresne worte:
>Just a theory, but 64x64 looks like Mali GPU requirement to me. Can you give
>more details how it fails exactly ?

Chromium failed when calling v4l2 uapi VIDIOC_STREAMON with size 16x16 and
V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY disabled. It has not come to render step
which will use gpu. Other decoders I have tested with chromium like
hantro g1 and rkvdec both don't have this 16x16 min width/height.

I also tried gstreamer with a 16x16 video and it works fine. So there
should be something wrong in chromium's code. But I have not find where
chromium set sps flags in its v4l2 decoder.

Best regards,
Jianfeng