[PATCH 1/3] media: rockchip: Introduce the rkvdec2 driver

[Nicolas Dufresne]

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:
> > Hi Detlev,
> > 
> > On Fri, 14 Jun 2024 21:56:27 -0400, Detlev Casanova wrote:
> > > +		.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

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