Video data from nvcsi interface gives corr_err

I am attempting to read video data from a camera (the LI-IMX490-GW5400-FPDLINKIII from leopard imaging, if this is relevant) which I have plugged into my agx xavier through the NVCSI interface. When I attempt to run a gstreamer pipeline to use the data, no error is thrown, but the pipeline does not produce data.

This is the error message that I see when I consult dmesg after running a gstreamer pipeline which uses video data from this camera:

[ 7520.401373] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 0, err_data 256
[ 7520.441342] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 0, err_data 256
[ 7520.481375] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 0, err_data 256
[ 7520.521436] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 0, err_data 256
[ 7520.561438] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 0, err_data 256
[ 7520.601464] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 0, err_data 256

with these messages being repeated at approx. 40ms intervals for the duration of the pipeline being run.

The simplest command I have tried which produces these error messages is:

gst-launch-1.0 v4l2src device="/dev/video6" ! video/x-raw, width=1920, height=1080, format=YUY2, framerate=30/1 ! fakesink

Looking through the kernel, I have traced the error to the function vi5_capture_dequeue in the file nvidia/drivers/media/platform/tegra/camera/vi/vi5_fops.c. It grabs a struct capture_descriptor, and this struct seems to have an error (hence err_data being 256). The struct is defined in nvidia/include/soc/tegra/camrtc-capture.h, which seems to indicate that this value for err_data is CAPTURE_STATUS_FLAG_ERROR_ATOMP_FRAME_TRUNCATED. However, I don’t know what to do with that information.

Is there a way to resolve this error coming from the jetson drivers, and actually get video data from my camera?

Have check if v4l2-ctl working.

v4l2-ctl --list-devices
v4l2-ctl --stream-mmap --stream-count=100 --set-ctrl bypass_mode=0 -d /dev/video0

@SimonZhu
Could you help to check if any comment for this.

Thanks

$ v4l2-ctl --list-devices
vi-output, imx390 30-001b (platform:15c10000.vi:0):
        /dev/video0
        /dev/video1

vi-output, imx390 31-001b (platform:15c10000.vi:2):
        /dev/video2
        /dev/video3

vi-output, imx390 32-001b (platform:15c10000.vi:4):
        /dev/video4
        /dev/video5

vi-output, imx390 33-001b (platform:15c10000.vi:5):
        /dev/video6
        /dev/video7

NVIDIA Tegra Video Input Device (platform:tegra194-vi5):
        /dev/media0
$ v4l2-ctl --stream-mmap --stream-count=100 --set-ctrl bypass_mode=0 -d /dev/video0 --verbose
VIDIOC_QUERYCAP: ok
VIDIOC_S_EXT_CTRLS: ok
                VIDIOC_REQBUFS returned 0 (Success)
                VIDIOC_QUERYBUF returned 0 (Success)
                VIDIOC_QUERYBUF returned 0 (Success)
                VIDIOC_QUERYBUF returned 0 (Success)
                VIDIOC_QUERYBUF returned 0 (Success)
                VIDIOC_QBUF returned 0 (Success)
                VIDIOC_QBUF returned 0 (Success)
                VIDIOC_QBUF returned 0 (Success)
                VIDIOC_QBUF returned 0 (Success)
                VIDIOC_STREAMON returned 0 (Success)

Running v4l2-ctl --stream-mmap --stream-count=100 --set-ctrl bypass_mode=0 -d /dev/video0 --verbose hangs at that point (it does not finish executing, nor does it output anything else, for several minutes). I added the --verbose flag because, without it, it hangs without outputting anything. This command also causes the same logs to appear in dmesg as I mentioned in my original post.

Update: It turns out that my camera was misconfigured. The drivers were expecting 1920x1080 video data, but the camera that I received from the manufacturer was misconfigured to exclusively send higher-resolution data, which led to the frame not matching what was expected and causing this error.

I’m working with the camera manufacturer to get things sorted out, but it looks like the issue is not being caused by the jetson.

@jarred1
The resolution of this IMX490-GW5400-FPDLNKIII camera should be 2880x1860.
We have TX2 driver for this camera and our TX2 FPDLINKIII box. You can download the patch files from link below for reference.

@SimonZhu Thanks for sending these drivers. They needed a few tweaks to the device tree to match the AGX Xavier hardware instead of the TX2, but my cameras work now!

Good to know it. Thanks.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.