Hi,

Le mardi 18 juin 2024 à 08:39 -0400, Detlev Casanova a écrit :

On Tuesday, June 18, 2024 8:13:29 A.M. EDT Jianfeng Liu wrote:

quoted

Hi Detlev,

On Fri, 14 Jun 2024 21:56:27 -0400, Detlev Casanova wrote:

quoted

+		.frmsize = {
+			.min_width = 16,
+			.max_width =  65520,
+			.step_width = 16,
+			.min_height = 16,
+			.max_height =  65520,
+			.step_height = 16,
+		},

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.

i,
Page 374 shows the sizes for h265. h264 is the next table, where 16x16 and 
65520x65520 is documented.

Just a theory, but 64x64 looks like Mali GPU requirement to me. Can you give
more details how it fails exactly ?

Meanwhile, if fluster suite does not exercise it already, we can craft a stream
to verify the its decodes fine. We also have issues in rkvdec were the driver
reports CAPTURE queue constraints for OUTPUT formats.

Nicolas

quoted

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:

quoted

+	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.

quoted

After changing them to 64 my chromium can use rkvdec2 to decode h264
videos now.

Anyway many thanks to your amazing work!

Best regards,
Jianfeng