Using the suggested debug commands it became obvious that buffer sizes are slightly mismatched, by only 4032:I.e. the image encoder /dev/video31 device wants a slightly larger buffer as input (OUTPUT stream in V4L2 terms) than it is provided by an ISP.
But why?
Turns out, the image encoder device wants a 2 pix higher image as an input (note the wanted 990 vs factual 992):even though it boasts stepwise divisible by 2 resolution support:I will try padding the ISP output somehow (I know how CROP works, but there doesn't seem to be any COMPOSE support).
Cropping things down, it seems that in reality the image encoder device wants the height to be divisible by 16, as the next highest supported height seems to be 976. Cropping the image to that works: the /dev/video31 happily compresses 1332x976 images into jpeg 120 frames per second. And this stream seems to work as an MJPEG stream too.
Thanks for the support!
Code:
videobuf2_common: [out-d2da0276] __prepare_dmabuf: invalid dmabuf length 1995840 for plane 0, minimum length 1999872But why?
Turns out, the image encoder device wants a 2 pix higher image as an input (note the wanted 990 vs factual 992):
Code:
[INF] Setting format V4L2_PIX_FMT_YUV420(32315559) 1332x990 for Devicestream=V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE(10)[INF] Set format:...[INF] pix_mp.width = 1332[INF] pix_mp.height = 992...[INF] pix_mp.plane_fmt[0].sizeimage = 1999872Code:
[INF] fmt[5] = {V4L2_PIX_FMT_YUV420, Planar YUV 4:2:0}[INF] fss.stepwise = [32..+2x..1920] x [32..+2x..1920]Cropping things down, it seems that in reality the image encoder device wants the height to be divisible by 16, as the next highest supported height seems to be 976. Cropping the image to that works: the /dev/video31 happily compresses 1332x976 images into jpeg 120 frames per second. And this stream seems to work as an MJPEG stream too.
Thanks for the support!
Statistics: Posted by provod — Wed Feb 21, 2024 9:47 pm