Dual cams: Cam #0 always works, cam#1 only works if cam #0 never run

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
1

Hi Forum,

I am working witJetpack-5.1.5 and dual IMX296 cameras. If I repeat the bellow command for the camera #1 only, it works well :

gst-launch-1.0 nvarguscamerasrc sensor-id=1 sensor-mode=0 ! 'video/x-raw(memory:NVMM),width=1456, height=1088, framerate=60/1, format=NV12' ! nvvidconv ! fpsdisplaysink text-overlay=0 name=sink_0 video-sink=fakesink sync=0 -v

But if I try same command for camera #0, then go back to camera #1, the camera #1 will not work anymore:

gst-launch-1.0 nvarguscamerasrc sensor-id=0 sensor-mode=0 ! 'video/x-raw(memory:NVMM),width=1456, height=1088, framerate=60/1, format=NV12' ! nvvidconv ! fpsdisplaysink text-overlay=0 name=sink_0 video-sink=fakesink sync=0 -v // Work

gst-launch-1.0 nvarguscamerasrc sensor-id=1 sensor-mode=0 ! 'video/x-raw(memory:NVMM),width=1456, height=1088, framerate=60/1, format=NV12' ! nvvidconv ! fpsdisplaysink text-overlay=0 name=sink_0 video-sink=fakesink sync=0 -v // does not work anymore

Restarting the nvargus-daemon does NOT help either.

Have you ever seen this before?

Thanks and best regards,
Khang

5

How about v4l2-ctl?

v4l2-ctl --stream-mmap -c bypass_mode=0 -d /dev/video0
v4l2-ctl --stream-mmap -c bypass_mode=0 -d /dev/video1
or 
v4l2-ctl --stream-mmap -c bypass_mode=0 -d /dev/video1
v4l2-ctl --stream-mmap -c bypass_mode=0 -d /dev/video0
6

Hi @ShaneCCC When gstreamer pipeline of cam#1 happened to stop working, v4l2 pipeline on cam#1 continued working.

7

Can they working simultaneously?

gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! nvvidconv ! fpsdisplaysink video-sink=fakesink text-overlay=false -v nvarguscamerasrc sensor-id=1 ! nvvidconv ! fpsdisplaysink video-sink=fakesink text-overlay=false -v
8

Hi @ShaneCCC ,

They could work if I repeated the gstreamer command immediately. However, if I stopped then waited about 5s or more before re-launching the command, they would NOT work anymore.

9

Any GMSL Serdes chip design.

I would suspect the sensor/GML chip didn’t reset will cause the problem.

10

Hi @ShaneCCC ,

It turned out that it was issue of the carrier board that did not properly control the reset signal (defined as PWDNx and used as input of reset-gpios property in the device-tree).

Changing the carrier board solved the problem. Thanks for your support.

1 Like
12

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