Jetson Xavier NX, gstCamera.cpp increasing timeout buffer

[ben276]

Hi all,

I’m using a Jetson Xavier NX running JetPack 4.6.4, OpenCV 4.8.0 and a USB camera.
I’m having a recurring issue with a custom jetson_inference script which will occasionally exit with one of these two errors:

gstCamera::Capture() -- an error occurred retrieving the next image buffer

gstCamera::Capture() -- a timeout occurred waiting for the next image buffer

The time between the errors is not uniform and ranges between 10 and 120 minutes.

After reading through gstCamera.cpp I’ve found that both of these errors are caused by const int result = mBufferManager->Dequeue(output, format, timeout, stream); returning either less than or equal to zero.

Is the best course of action to increase the timeout buffer or modify the capture function to ‘skip’ a dropped image?

Thanks in advance.

[DaneLLL]

Hi,
Please refer to the steps to try gat-launch-1.0 command:

Jetson Xavier NX FAQ
Q: I have a USB camera. How can I launch it on Xavier NX?

To clarify whether the issue happens only when running jetson_inference. To check if it is an issue in application level, or the camera is not stable.

[ben276]

I tried launching gst-launch-1.0 with this command:

$ gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw,format=YUY2,width=640,height=480,framerate=30/1 ! nvvidconv ! 'video/x-raw(memory:NVMM),format=NV12' ! nvoverlaysink

(including many different variations in width, height, framerate and raw format)
and the camera wasn’t able to open at all.
Running v4l2-ctl --list-devices returns /dev/video0 but even cheese can’t detect the camera.

In my jetson_inference script I can successfully open the camera with this constructor:

camera = videoSource("/dev/video0", options={'width': 1920, 'height': 1080, 'framerate': 30})

[DaneLLL]

Hi,
Please run the command and share the prints for reference:

$ v4l2-ctl -d /dev/video0 --list-formats-ext

[ben276]

ioctl: VIDIOC_ENUM_FMT
	Index       : 0
	Type        : Video Capture
	Pixel Format: 'MJPG' (compressed)
	Name        : Motion-JPEG
		Size: Discrete 1920x1080
			Interval: Discrete 0.017s (60.000 fps)
			Interval: Discrete 0.033s (30.000 fps)
			Interval: Discrete 0.067s (15.000 fps)
		Size: Discrete 4032x3040
			Interval: Discrete 0.100s (10.000 fps)
		Size: Discrete 3840x2160
			Interval: Discrete 0.050s (20.000 fps)
		Size: Discrete 2592x1944
			Interval: Discrete 0.033s (30.000 fps)
			Interval: Discrete 0.067s (15.000 fps)
		Size: Discrete 2560x1440
			Interval: Discrete 0.033s (30.000 fps)
			Interval: Discrete 0.067s (15.000 fps)
		Size: Discrete 1600x1200
			Interval: Discrete 0.020s (50.000 fps)
			Interval: Discrete 0.033s (30.000 fps)
			Interval: Discrete 0.067s (15.000 fps)
		Size: Discrete 1280x960
			Interval: Discrete 0.010s (100.000 fps)
			Interval: Discrete 0.013s (80.000 fps)
			Interval: Discrete 0.017s (60.000 fps)
			Interval: Discrete 0.033s (30.000 fps)
			Interval: Discrete 0.067s (15.000 fps)
		Size: Discrete 1280x720
			Interval: Discrete 0.010s (100.000 fps)
			Interval: Discrete 0.013s (80.000 fps)
			Interval: Discrete 0.017s (60.000 fps)
			Interval: Discrete 0.033s (30.000 fps)
			Interval: Discrete 0.067s (15.000 fps)
		Size: Discrete 640x480
			Interval: Discrete 0.013s (80.000 fps)
			Interval: Discrete 0.017s (60.000 fps)
			Interval: Discrete 0.033s (30.000 fps)
			Interval: Discrete 0.067s (15.000 fps)

[dusty_nv]

Hi @ben276, in the event of spurious connection issues, you can implement higher-level logic that detects if there are N timeouts, then destroy & recreate the videoSource device, and it should reconnect to the camera.

[ben276]

Thanks Dusty, much appreciated!

[ben276]

Posting for anyone in the future:

If you implement higher-level logic to close and reopen a videoSource device on a machine with multiple cameras, you will need to write custom udev rules so the respective functions can distinguish between different devices, as the Linux kernel will reassign device nodes based on the disconnection order.