Gstreamer doesn't detect second camera

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
,
1

Hi,

this is a follow-up to Capture not working on second camera.
I now can get both IMX492 cameras working using V4L2 on my Floyd setup (Xavier NX) with Jetpack 5.1.2/R35.4.1.
I can also use gstreamer to stream from the first camera:
gstreamer_cam0_ok_log.txt (4.0 KB)

Using the same command and just changing the sensor-id from 0 to 1, I get the following error :
Invalid camera device specified 1 specified, 0 max index

console output is the following:
gstreamer_cam1_fail_log.txt (1.2 KB)

This used to work when I was on Jetpack 4.6.1/R32.x.

Again, V4L2 for the same board+cameras works just fine: I can list supported formats, acquire images, control the sensor (exposure, gain), etc so definitely nothing wrong at the HW level.
list_formats_log.txt (3.7 KB)
media-ctrl_log.txt (2.2 KB)

This is specific to gstreamer and can’t find any useful information to troubleshoot this issue. Any idea?

Thanks,
Alain

3

hello alain.gautherot,

this looks incorrect. it’s reporting you’ve only 1-camera available in the system.
could you please try Applications Using V4L2 IOCTL Directly to use V4L2 IOCTL to test your 2nd camera stream.

4

Hi Jerry,

I had to recompile the gstreamer plugins with 10-bit bayer support for be able to use the plugin v4l2src.
I followed the thread instruction from here, but had to make corrections to the patch, add the missing dependency on openssl, and use C++11 for compiling to be pass.

For those interested, here are the resulting patch and script got gstreamer v1.16.3:
0001-Add-Bayer10-V4l2-support.patch (3.2 KB)
gst_build_with_raw10.sh (2.2 KB)

With these updated plugins, I run:

  • V4l2 to select 10-bit mode on /dev/video0 or 1:
    v4l2-ctl --set-fmt-video=width=8432,height=5648,pixelformat=RG10 --set-ctrl sensor_mode=1,bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=imx492_10bit.raw -d /dev/video0

  • run gstreamer on /dev/video0 or 1:
    gst-launch-1.0 v4l2src device=/dev/video0 ! ‘video/x-bayer, format=rggb, width=8432, height=5648, framerate=10/1’ ! bayer2rgb ! videoconvert ! xvimagesink -e

console output shows a lot of messages “A lot of buffers are being dropped”, but I can see frames are captured from either cameras:
gst_v4l2src_cam0_log.txt (3.4 KB)
gst_v4l2src_cam1_log.txt (3.7 KB)

Images don’t look good, but I can recognize expected shapes so it’s just a matter of :

gst_v4l2src_cam0
gst_v4l2src_cam01920×1141 360 KB

gst_v4l2src_cam1
gst_v4l2src_cam11920×1141 369 KB

I’m not sure what to conclude here, but this definitely feels similar to the issue I was reporting in my previous thread.
I got V4L2 working on the second camera after setting vc-id=0 instead of the initial vc-id=1.
Maybe a similar setting specific to gstreamer is incorrect?

5

hello alain.gautherot,

I’m kind of confused here…
is it still an issue, Invalid camera device specified 1 specified, 0 max index as your issue description?
as mentioned by Topic 256569, comment#42, you’ve resolve 2nd camera cannot detect by revising vc-id device tree property, correct?

there should be two different camera preview frames according to those screenshots.
they seen like some issues with stride alignment, or, incorrect debayer types.
for stride alignment…
you may try adding preferred_stride controls, and dump the image for checking.
for example, v4l2-ctl --set-fmt-video=width=8432,height=5648,pixelformat=RG10 --set-ctrl preferred_stride=8448 --set-ctrl sensor_mode=1, bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=imx492_10bit.raw -d /dev/video0

please try to preview the raw content, imx492_10bit.raw with 3rdparty tools, such as 7yuv.
there’re options to change the debayer types. please check you’re able to obtain correct results.

6

Jerry,
after changing to “vc-id=0”, I see the following:

  • v4l2-ctl capture from /dev/video0 in 10-bit and 12-bit: OK
  • v4l2-ctl capture from /dev/video1 in 10-bit and 12-bit: OK
  • gst-launch-1.0 nvarguscamerasrc ... from /dev/video0 in 10-bit and 12-bit: OK
  • gst-launch-1.0 nvarguscamerasrc ... from /dev/video1: FAIL with Invalid camera device specified 1 specified, 0 max index

I ran your experiment with gst-launch v4lsrc ... and after some struggle to get v4lsrc handle 10-bit output, got it to run.
I guess the conclusion is that there’s something that prevents nvarguscamerasrc from finding the second camera.

In this other thread, similar issue was fixed by changing the DTS (related to drivernode), but there’s no details.

I’ll look at the source code for nvarguscamerasrc, but do you have any idea what the issue could be?

7

hello alain.gautherot,

it’s the node definitions,
please review the settings within tegra-camera-platform,
for instance,
it’s module0 and module0 as two cameras in the system, and these two node were using drivernode0 to define the sensor info.

        tegra-camera-platform {
                compatible = "nvidia, tegra-camera-platform";

                modules {
                        module0 {
                                drivernode0 {
                         ...
                        module1 {
                                drivernode0 {
8

ok I found the issue in the DTS and changed from:

                                cam_module2_drivernode0: drivernode0 {
                                        pcl_id = "v4l2_sensor";
                                        devname = "eimx462 32-0042";
                                        proc-device-tree = "/proc/device-tree/i2c@3180000/tca9548@70/i2c@2/eimx462_e@42";
                                };

to

                               cam_module2_drivernode0: drivernode0 {
                                       pcl_id = "v4l2_sensor";
                                       devname = "eimx462 32-0042";
                                       proc-device-tree = "/proc/device-tree/i2c@3180000/**tca9564**@70/i2c@2/eimx462_e@42";
                               };

the path to the DT node was incorrect for the 3rd camera, although it was correct for the second camera.
I didn’t bother correcting it because the 3rd camera was not used (driver not loaded).

porting to jetpack 5 is now complete, but boy, was that painful!
Thanks for all the help!
Alain

10

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