<div dir="auto"><div>Hi,<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 13 juin 2023, 05 h 19, Peter Allen <<a href="mailto:peter.allenm@gmail.com">peter.allenm@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thank you for the reply, that's helpful to look at. I've had a look at the logs, and nothing looks obviously wrong to me, but I could easily have missed something.</div><div>Just a quick flag: I don't appear to have implemented colorspaces very well in the driver. bt709 seems fine, but bt601 fails. Is this likely to be an issue?<br></div><div><br></div><div>I'm running kernel 5.8 at the moment (I need to update the MIPI drivers to 6.x, but that's for the future.)</div><div>Edited highlights:</div><div>[ 69.180326] get_colorspace(352): csi1: fmt=842094158<br>[ 69.185378] video0: VIDIOC_TRY_FMT: type=vid-cap, width=32, height=32, pixelformat=NV12, field=none, bytesperline=48, sizeimage=1536,</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Wrong bytesperline, should be 32</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> colorspace=3, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0<br>[ 69.186474] get_colorspace(352): csi1: fmt=842094158<br>[ 69.191493] video0: VIDIOC_TRY_FMT: type=vid-cap, width=4800, height=4800, pixelformat=NV12, field=none, bytesperline=7200, sizeimage=34560000,</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Same, -> 4800</div><div dir="auto"><br></div><div dir="auto">Consider using the helpers in v4l2-common.c instead of free coding these. Oversized bytesperline causes an overflow in GStreamer.</div><div dir="auto"><br></div><div dir="auto">Nicolas</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> colorspace=3, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0<br>[ 69.191776] video0: VIDIOC_ENUM_FRAMESIZES: error -25: index=0, pixelformat=RGBP, type=0</div><div><br></div><div>[ 69.264850] get_colorspace(352): csi1: fmt=842094158<br>[ 69.269922] video0: VIDIOC_TRY_FMT: type=vid-cap, width=1280, height=720, pixelformat=NV12, field=none, bytesperline=1920, sizeimage=1382400, colorspace=3, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0<br>[ 69.275872] get_colorspace(352): csi1: fmt=842094158<br>[ 69.282676] video0: VIDIOC_S_FMT: type=vid-cap, width=1280, height=720, pixelformat=NV12, field=none, bytesperline=1920, sizeimage=1382400, colorspace=3, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0<br>[ 69.282740] video0: VIDIOC_G_PARM: error -25: type=vid-cap, capability=0x0, capturemode=0x0, timeperframe=0/0, extendedmode=0, readbuffers=0</div><div><br></div><div>I'm figuring the error -25 and error -22 type things are "not implemented" so aren't showstoppers, but I haven't actually checked yet.</div><div><br></div><div>[ 69.303031] video0: VIDIOC_QUERYBUF: 00:00:00.000000000 index=0, type=vid-cap, request_fd=0, flags=0x00002000, field=any, sequence=0, memory=mmap, bytesused=0, offset/userptr=0x0, length=1382400</div><div>(then 4 other buffers)</div><div><br></div><div>[ 69.345269] video0: VIDIOC_STREAMON: type=vid-cap<br>[ 69.347906] videodev: v4l2_poll: video0: poll: 00000000<br>[ 69.369241] videodev: v4l2_poll: video0: poll: 00000041<br>[ 69.369297] video0: VIDIOC_DQBUF: 00:01:09.000366895 index=0, type=vid-cap, request_fd=0, flags=0x00002001, field=none, sequence=0, memory=mmap, bytesused=1382400, offset/userptr=0x0, length=1382400<br>[ 69.369324] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000<br>[ 69.369645] video0: VIDIOC_QBUF: 00:00:00.000000000 index=0, type=vid-cap, request_fd=0, flags=0x00002003, field=none, sequence=0, memory=mmap, bytesused=1382400, offset/userptr=0x0, length=1382400<br>[ 69.369670] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000<br>[ 69.381785] hdzerocam_s_stream(755)<br>[ 69.387749] video0: VIDIOC_STREAMOFF: type=vid-cap<br>[ 69.388817] video0: VIDIOC_REQBUFS: count=0, type=vid</div><div><br></div><div>Full log attached.</div><div><br></div><div>Thank you for the help, it is much appreciated!<br></div><div>Pete<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 12 Jun 2023 at 20:53, Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca" target="_blank" rel="noreferrer">nicolas@ndufresne.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div>Hi,</div><div><br></div><div>Le dimanche 11 juin 2023 à 22:45 +0100, Peter Allen via gstreamer-devel a écrit :</div><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><div dir="ltr"><div>Hi All,</div><div><br></div><div>I am attempting to use gstreamer with a camera I've had to write the driver for on a relatively untested arm board (an Allwinner S3). And guess what - I've got issues :)</div><div><br></div><div>The camera has an onboard ISP, so produces UYVY 422p on Mipi CSI, and the MIPI peripheral has the capability to convert between different YUV formats In fact interleaved UYVY comes out in a really weird byte order, so I've been using NV12 or NV16 as it is correct. When I use v4l2-ctl to produce the stream, all is well:</div><div><br></div><div>v4l2-ctl --set-fmt-video=width=1280,height=720,pixelformat=NV12 --stream-mmap --stream-count=600 --silent -d /dev/video0 --stream-to=MyFile.raw</div><div><br></div><div>However when I try to do similar things with gstreamer, I have issues:</div><div>gst-launch-1.0 -ve v4l2src device=/dev/video0 ! video/x-raw,width=1280,height=720,framerate=60/1,format=NV12 ! queue ! filesink location=GstNV12Raw.raw</div><div><br></div><div>gives:</div><div>ot@openhd-x20dev:/home/openhd# gst-launch-1.0 -ve v4l2src device=/dev/video0 ! video/x-raw,width=1280,height=720,framerate=60/1,format=NV12 ! queue ! filesink location=GstNV12Raw.raw<br>[ 2048.216638] hdzerocam_open(816)<br>[ 2048.219869] hdzerocam_fill_fmt(805): HDZero fill<br>Setting pipeline to PAUSED ...<br>Pipeline is live and does not need PREROLL ...<br>Pipeline is PREROLLED ...<br>Setting pipeline to PLAYING ...<br>New clock: GstSystemClock<br>/GstPipeline:pipeline0/GstV4l2Src:v4l2src0.GstPad:src: caps = video/x-raw, width=(int)1280, height=(int)720, framerate=(fraction)60/1, format=(string)NV12, interlace-m[ 2048.274807] hdzerocam_get_fmt(710)<br>ode=(string)progressive, colorimetry=(string)2:0:0:0<br>/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = video/[ 2048.290307] hdzerocam_s_stream(755)<br>x-raw, width=(int)1280, height=(int)720, framerate=(fraction)60/1, format=(string)NV12, interlace-mode=(string)progressive, colorimetry=(string)2:0:0:0<br>/GstPipeline:pipeline0/GstQueue:queue0.[ 2048.309943] hdzerocam_s_stream(755)<br>GstPad:src: caps = video/x-raw, width=(int)1280, height=(int)720, framerate=(fraction)60/1, format=(string)NV12, interlace-mode=(string)progressive, colorimetry=(string)2:0:0:0<br>/GstPipeline:pipeline0/GstFileSink:filesink0.GstPad:sink: caps = video/x-raw, width=(int)1280, height=(int)720, framerate=(fraction)60/1, format=(string)NV12, interlace-mode=(string)progressive, colorimetry=(string)2:0:0:0<br>/GstPipeline:pipeline0/GstQueue:queue0.GstPad:sink: caps = video/x-raw, width=(int)1280, height=(int)720, framerate=(fraction)60/1, format=(string)NV12, interlace-mode=(string)progressive, colorimetry=(string)2:0:0:0<br>/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = video/x-raw, width=(int)1280, height=(int)720, framerate=(fraction)60/1, format=(string)NV12, interlace-mode=(string)progressive, colorimetry=(string)2:0:0:0<br>0:00:00.159656333 443 0x5b4c58 WARN video-info video-info.c:204:validate_colorimetry: Need to specify a color matrix when using YUV format (NV12)<br>0:00:00.159812875 443 0x5b4c58 WARN video-info video-info.c:520:gst_video_info_from_caps: invalid colorimetry, using default<br>0:00:00.161243625 443 0x5b4c58 WARN video-info video-info.c:204:validate_colorimetry: Need to specify a color matrix when using YUV format (NV12)<br>0:00:00.161350333 443 0x5b4c58 WARN video-info video-info.c:520:gst_video_info_from_caps: invalid colorimetry, using default<br>0:00:00.161923083 443 0x5b4c58 WARN video-info video-info.c:204:validate_colorimetry: Need to specify a color matrix when using YUV format (NV12)<br>0:00:00.162008667 443 0x5b4c58 WARN video-info video-info.c:520:gst_video_info_from_caps: invalid colorimetry, using default<br>0:00:00.162248167 443 0x5b4c58 WARN video-info video-info.c:204:validate_colorimetry: Need to specify a color matrix when using YUV format (NV12)<br>0:00:00.162310958 443 0x5b4c58 WARN video-info video-info.c:520:gst_video_info_from_caps: invalid colorimetry, using default<br>0:00:00.172358583 443 0x5b4c58 WARN v4l2bufferpool gstv4l2bufferpool.c:814:gst_v4l2_buffer_pool_start:<v4l2src0:pool0:src> Uncertain or not enough buffers, enabling copy threshold<br>0:00:00.205794042 443 0x5b4c58 ERROR videometa gstvideometa.c:242:default_map: plane 1, no memory at offset 1382400<br>0:00:00.205912917 443 0x5b4c58 ERROR default video-frame.c:168:gst_video_frame_map_id: failed to map video frame plane 1<br>0:00:00.206110167 443 0x5b4c58 ERROR v4l2bufferpool gstv4l2bufferpool.c:161:gst_v4l2_buffer_pool_copy_buffer:<v4l2src0:pool0:src> could not map buffer<br>0:00:00.206237458 443 0x5b4c58 ERROR v4l2bufferpool gstv4l2bufferpool.c:2071:gst_v4l2_buffer_pool_process:<v4l2src0:pool0:src> failed to copy buffer</div></div></blockquote><div><br></div><div>I think GStreamer is trying to copy the image to remove the HW specific padding. The reported stride (bytesperline in V4L2) might be a little bit off. The v4l2-ctl utilise does not do line per line copies, so it does not use it. If you can build v4l2-utils and use v4l2-tracer tracer ... to spy on the exchange between gst and the kernel I'd be able to tell.</div><div><br></div><div>An alternative is to enable some kernel debug, which should be sufficient for this case:</div><div><br></div><div>sudo su -c "echo 0xff > /sys/class/video4linux/video0/dev_debug"</div><div><br></div><div>Run gst, and then the output will be in "dmesg". Don't forget to echo 0, or to reboot, this can slow down a lot the driver.</div><div><br></div><div>Nicolas</div><div><br></div><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><div dir="ltr"><div>0:00:00.206398958 443 0x5b4c58 WARN basesrc gstbasesrc.c:3127:gst_base_src_loop:<v4l2src0> error: Internal data stream error.<br>0:00:00.206471292 443 0x5b4c58 WARN basesrc gstbasesrc.c:3127:gst_base_src_loop:<v4l2src0> error: streaming stopped, reason error (-5)<br>ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data stream error.<br>Additional debug info:<br>../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:<br>streaming stopped, reason error (-5)<br>Execution ended after 0:00:00.057735709<br>Setting pipeline to NULL ...<br>Freeing pipeline ...<br></div><div><br></div><div>----------------------------------------------------</div><div>i'm well aware that this might not be gstreamer's issue, but I'm really struggling to understand what is going on with gstvideometa.c:242:default_map: plane 1, no memory at offset 1382400</div><div><br></div><div>Full GST_DEBUG_LEVEL=4 attached in case it helps.</div><div><br></div><div>Can anyone shed some light?</div><div>Thank you</div><div>Pete<br></div></div></blockquote><div><br></div><div><span></span></div></div> </div></blockquote></div> </blockquote></div></div></div>