v4l2src fail - but could be buggy driver
Nicolas Dufresne
nicolas at ndufresne.ca
Tue Jun 13 11:52:02 UTC 2023
Hi,
Le mar. 13 juin 2023, 05 h 19, Peter Allen <peter.allenm at gmail.com> a
écrit :
> 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.
> 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?
>
> 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.)
> Edited highlights:
> [ 69.180326] get_colorspace(352): csi1: fmt=842094158
> [ 69.185378] video0: VIDIOC_TRY_FMT: type=vid-cap, width=32, height=32,
> pixelformat=NV12, field=none, bytesperline=48, sizeimage=1536,
>
Wrong bytesperline, should be 32
colorspace=3, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [ 69.186474] get_colorspace(352): csi1: fmt=842094158
> [ 69.191493] video0: VIDIOC_TRY_FMT: type=vid-cap, width=4800,
> height=4800, pixelformat=NV12, field=none, bytesperline=7200,
> sizeimage=34560000,
>
Same, -> 4800
Consider using the helpers in v4l2-common.c instead of free coding these.
Oversized bytesperline causes an overflow in GStreamer.
Nicolas
colorspace=3, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [ 69.191776] video0: VIDIOC_ENUM_FRAMESIZES: error -25: index=0,
> pixelformat=RGBP, type=0
>
> [ 69.264850] get_colorspace(352): csi1: fmt=842094158
> [ 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
> [ 69.275872] get_colorspace(352): csi1: fmt=842094158
> [ 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
> [ 69.282740] video0: VIDIOC_G_PARM: error -25: type=vid-cap,
> capability=0x0, capturemode=0x0, timeperframe=0/0, extendedmode=0,
> readbuffers=0
>
> 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.
>
> [ 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
> (then 4 other buffers)
>
> [ 69.345269] video0: VIDIOC_STREAMON: type=vid-cap
> [ 69.347906] videodev: v4l2_poll: video0: poll: 00000000
> [ 69.369241] videodev: v4l2_poll: video0: poll: 00000041
> [ 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
> [ 69.369324] timecode=00:00:00 type=0, flags=0x00000000, frames=0,
> userbits=0x00000000
> [ 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
> [ 69.369670] timecode=00:00:00 type=0, flags=0x00000000, frames=0,
> userbits=0x00000000
> [ 69.381785] hdzerocam_s_stream(755)
> [ 69.387749] video0: VIDIOC_STREAMOFF: type=vid-cap
> [ 69.388817] video0: VIDIOC_REQBUFS: count=0, type=vid
>
> Full log attached.
>
> Thank you for the help, it is much appreciated!
> Pete
>
> On Mon, 12 Jun 2023 at 20:53, Nicolas Dufresne <nicolas at ndufresne.ca>
> wrote:
>
>> Hi,
>>
>> Le dimanche 11 juin 2023 à 22:45 +0100, Peter Allen via gstreamer-devel a
>> écrit :
>>
>> Hi All,
>>
>> 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 :)
>>
>> 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:
>>
>> v4l2-ctl --set-fmt-video=width=1280,height=720,pixelformat=NV12
>> --stream-mmap --stream-count=600 --silent -d /dev/video0
>> --stream-to=MyFile.raw
>>
>> However when I try to do similar things with gstreamer, I have issues:
>> 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
>>
>> gives:
>> ot at 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
>> [ 2048.216638] hdzerocam_open(816)
>> [ 2048.219869] hdzerocam_fill_fmt(805): HDZero fill
>> Setting pipeline to PAUSED ...
>> Pipeline is live and does not need PREROLL ...
>> Pipeline is PREROLLED ...
>> Setting pipeline to PLAYING ...
>> New clock: GstSystemClock
>> /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)
>> ode=(string)progressive, colorimetry=(string)2:0:0:0
>> /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps =
>> video/[ 2048.290307] hdzerocam_s_stream(755)
>> 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
>> /GstPipeline:pipeline0/GstQueue:queue0.[ 2048.309943]
>> hdzerocam_s_stream(755)
>> 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
>> /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
>> /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
>> /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
>> 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)
>> 0:00:00.159812875 443 0x5b4c58 WARN video-info
>> video-info.c:520:gst_video_info_from_caps: invalid colorimetry, using
>> default
>> 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)
>> 0:00:00.161350333 443 0x5b4c58 WARN video-info
>> video-info.c:520:gst_video_info_from_caps: invalid colorimetry, using
>> default
>> 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)
>> 0:00:00.162008667 443 0x5b4c58 WARN video-info
>> video-info.c:520:gst_video_info_from_caps: invalid colorimetry, using
>> default
>> 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)
>> 0:00:00.162310958 443 0x5b4c58 WARN video-info
>> video-info.c:520:gst_video_info_from_caps: invalid colorimetry, using
>> default
>> 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
>> 0:00:00.205794042 443 0x5b4c58 ERROR videometa
>> gstvideometa.c:242:default_map: plane 1, no memory at offset 1382400
>> 0:00:00.205912917 443 0x5b4c58 ERROR default
>> video-frame.c:168:gst_video_frame_map_id: failed to map video frame plane 1
>> 0:00:00.206110167 443 0x5b4c58 ERROR v4l2bufferpool
>> gstv4l2bufferpool.c:161:gst_v4l2_buffer_pool_copy_buffer:<v4l2src0:pool0:src>
>> could not map buffer
>> 0:00:00.206237458 443 0x5b4c58 ERROR v4l2bufferpool
>> gstv4l2bufferpool.c:2071:gst_v4l2_buffer_pool_process:<v4l2src0:pool0:src>
>> failed to copy buffer
>>
>>
>> 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.
>>
>> An alternative is to enable some kernel debug, which should be sufficient
>> for this case:
>>
>> sudo su -c "echo 0xff > /sys/class/video4linux/video0/dev_debug"
>>
>> 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.
>>
>> Nicolas
>>
>> 0:00:00.206398958 443 0x5b4c58 WARN basesrc
>> gstbasesrc.c:3127:gst_base_src_loop:<v4l2src0> error: Internal data stream
>> error.
>> 0:00:00.206471292 443 0x5b4c58 WARN basesrc
>> gstbasesrc.c:3127:gst_base_src_loop:<v4l2src0> error: streaming stopped,
>> reason error (-5)
>> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal
>> data stream error.
>> Additional debug info:
>> ../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop ():
>> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
>> streaming stopped, reason error (-5)
>> Execution ended after 0:00:00.057735709
>> Setting pipeline to NULL ...
>> Freeing pipeline ...
>>
>> ----------------------------------------------------
>> 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
>>
>> Full GST_DEBUG_LEVEL=4 attached in case it helps.
>>
>> Can anyone shed some light?
>> Thank you
>> Pete
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230613/d9680546/attachment.htm>
More information about the gstreamer-devel
mailing list