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
