you may also check the Camera Architecture Stack, [Camera Core] will handle the processing when you configure bypass mode.
here’s sample command to configure bypass mode settings.
I tried the v4l2-ctl command using bypass mode, but the behaviour is same (getting same error as per comment #13).
Is it possible to modify tegra camera framework so that it will not consider the sync pulse on MIPI clock…? and fill the buffer with data available on MIPI bus.
you’re actually getting frames, but there are some short frame error reporting as below.
please double confirm you had configure correct frame width/height in device tree.
[14404.221042] video4linux video0: TEGRA_VI_CSI_ERROR_STATUS 0x00000004
[14404.228122] vi 54080000.vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000180
We were able to get video data after changing the virtual channel configuration in camera sensor.
Previous configuration had two virtual channels, which was probably causing the issue. Extra Start frame error we were getting earlier was likely due to the 2 virtual channels enabled as sensor was sending MIPI output with 2 Start frames.
With the new configuration of Sensor, we have one virtual channel and driver/framework no longer reports error. Further we also get correct data in the v4l2 buffers, most of the time.
We now see that 3 out of 4 frames received from V4L2 are having all zeroes, and 1 frame has correct data. We do not see any errors reported in dmesg log.
What could be the reason of getting some of the frames with all zeros…?
I can not stream the camera using nvarguscamerasrc as it is custom camera sensor.
I am using the v4l2-ctl command to test the camera output.
terminal log -
jetson@jetson:~$ v4l2-ctl -d /dev/video0 -w --verbose --set-fmt-video=width=672,height=750,pixelformat=RG12 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=3 --stream-to=data.raw
Opening in BLOCKING MODE
VIDIOC_QUERYCAP: ok
VIDIOC_S_EXT_CTRLS: ok
VIDIOC_G_FMT: ok
VIDIOC_S_FMT: ok
Format Video Capture:
Width/Height : 672/750
Pixel Format : 'RG12'
Field : None
Bytes per Line : 1344
Size Image : 1008000
Colorspace : sRGB
Transfer Function : Default (maps to sRGB)
YCbCr/HSV Encoding: Default (maps to ITU-R 601)
Quantization : Default (maps to Full Range)
Flags :
VIDIOC_REQBUFS: ok
VIDIOC_QUERYBUF: ok
VIDIOC_QBUF: ok
VIDIOC_QUERYBUF: ok
VIDIOC_QBUF: ok
VIDIOC_QUERYBUF: ok
VIDIOC_QBUF: ok
VIDIOC_QUERYBUF: ok
VIDIOC_QBUF: ok
VIDIOC_STREAMON: ok
Index : 0
Type : Video Capture
Flags : mapped
Field : None
Sequence : 0
Length : 1008000
Bytesused: 1008000
Timestamp: 0.000000s (Monotonic, End-of-Frame)
Index : 1
Type : Video Capture
Flags : mapped
Field : None
Sequence : 1
Length : 1008000
Bytesused: 1008000
Timestamp: 0.000000s (Monotonic, End-of-Frame)
Index : 2
Type : Video Capture
Flags : mapped
Field : None
Sequence : 2
Length : 1008000
Bytesused: 1008000
Timestamp: 0.000000s (Monotonic, End-of-Frame)
VIDIOC_STREAMOFF: ok
here’s line width failure from the kernel log, you should update device tree to correct it.
please also access [Tegra X1 (SoC) Technical Reference Manual] from Jetson Download Center, and you could check the session [31.2.6.1 VI Error Status and Interrupts] for the TEGRA_VI_CSI_ERROR_STATUS reporting.
sensor 3A settings were execute in the sensor kernel driver, you may check CID controls to have more details.
for example,
We able to resolve the issue of blank frames (all zero data).
We were getting line width error as sensor was sending extra data of 4 pixel data,
After re-configuring the sensor, we are getting valid frame data.