Gstreamer command pipeline parameters for testing Sony IMX273

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
1

Hi Team,

I am using the Alvium 1800 C-158 camera with the Jetson Xavier NX which has the Sony IMX273 sensor.
I am trying to debug the camera access after installing the drivers as specified at GitHub - alliedvision/linux_nvidia_jetson: Allied Vision CSI-2 camera driver for NVIDIA Jetson Systems. Currently supporting Nano, TX2, AGX Xavier, and Xavier NX. Support for TX2 NX coming soon.
I am running the following command -

gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw, format=BGRx ! videoconvert ! appsink

This works fine as is but when I alter the command to include some other parameters like width, height, framerate under the video/x-raw (a list of parameters is available here - v4l2src) the pipeline errors out

gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw, format=BGRx, framerate=30/1 ! videoconvert ! appsink

ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data stream error

Does someone on this forum have more experience with this camera or with the Sony IMX273 sensor? Is it somehow unable to provide the video at this framerate leading to the failure?

Regards,
Ritvik

3

It’s bayer sensor? You may need to use argus, v4l2src only can capture RAW data only.

You can check the sensor format and sensor mode by below command.

v4l2-ctl --list-formats-ext
4

Here’s the output of the command -

ioctl: VIDIOC_ENUM_FMT
Index : 0
Type : Video Capture
Pixel Format: ‘TP31’
Name : 0x31 MIPI DATATYPE
Size: Discrete 1456x1088
Interval: Discrete 0.020s (50.847 fps)

Index : 1
Type : Video Capture
Pixel Format: ‘RGGB’
Name : 8-bit Bayer RGRG/GBGB
Size: Discrete 1456x1088
Interval: Discrete 0.020s (50.847 fps)

Index : 2
Type : Video Capture
Pixel Format: ‘RG16’
Name : 16-bit Bayer RGRG/GBGB (Exp.)
Size: Discrete 1456x1088
Interval: Discrete 0.020s (50.847 fps)

Index : 3
Type : Video Capture
Pixel Format: ‘RG16’
Name : 16-bit Bayer RGRG/GBGB (Exp.)
Size: Discrete 1456x1088
Interval: Discrete 0.020s (50.847 fps)

Index : 4
Type : Video Capture
Pixel Format: ‘BX24’
Name : 32-bit XRGB 8-8-8-8
Size: Discrete 1456x1088
Interval: Discrete 0.020s (50.847 fps)

Index : 5
Type : Video Capture
Pixel Format: ‘XR24’
Name : 32-bit BGRX 8-8-8-8
Size: Discrete 1456x1088
Interval: Discrete 0.020s (50.847 fps)

Index : 6
Type : Video Capture
Pixel Format: ‘VYUY’
Name : VYUY 4:2:2
Size: Discrete 1456x1088
Interval: Discrete 0.020s (50.847 fps)

I can see here that in all the formats, the size is always 1456x1088 which is same as the full resolution of the camera. Does it mean that I cannot capture images at a different resolution? Or would I be able to do this with argus?
I am not sure if its a bayer sensor, I could not find this mentioned in the specs.

5

I don’t think it can support all of those formats. Usually normal sensor only support one or two output format.

6

How can I create the gstreamer pipeline with argus? Would it be like the commands mentioned in the documentation here - https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/accelerated_gstreamer.html#wwpID0E0LR0HA

7

Yes, but you may need to follow this doc to confirm the driver been implement well first.

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/camera_sensor_prog.html#wwpID0E0LF0HA

8

Hi @ShaneCCC thanks for your help on this one so far.

I am not sure if the driver is properly implemented.
The first test gets stuck and starts throwing a lot of OS errors.

The second test just outputs:

VIDIOC_S_FMT: failed: Invalid argument
0.46 fps
0.46 fps
0.46 fps
0.46 fps
0.46 fps
0.46 fps

I’ll get back to you on this after I check with the Allied Vision support team.

Regards,
Ritvik

9

Hi @ShaneCCC while i was still unable to build a gstreamer command to adjust the resolution and camera FPS, i was able to do it with v4l2-ctrl.

v4l2-ctl -d /dev/video0 --set-crop=left=0,top=0,width=480,height=360
v4l2-ctl -d /dev/video0 -p 150

This solves my original problem for now.
Thanks for your help on this issue.

Regards,
Ritvik