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?
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.
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?
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.
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?
it’s the node definitions,
please review the settings within tegra-camera-platform,
it’s module0 and module0 as two cameras in the system, and these two node were using drivernode0 to define the sensor info.