Camera Streaming Issue in orin nx

Hi,
I am using Jetson_Linux_R35.4.1_aarch64.

I am using a custom carrier board based on the Orin NX, with two cameras connected. When Board is up for the first time and I start streaming using nv3dsink it is working properly as expected.

But after that if I use filesink and record the video using the WIFI it is recording the video but the video i am getting is black/corrupted screen.

And this is strange but when I use filesink first and record the video using WIFI it will record properly and I can see the video after downloading it.. But just after that If I run the nv3dsink it’ll stream the black/corrupted video.

Also I have noticed that the video file size of when recorded properly and can see the video is much larger then the video file size of when black/corrupted size.

Now if i use nv3dsink multiple times on the board it is giving properly visible camera stream. but if i use nv3dsink and use fakesink after that there will be no crash in fakesink but after that if i use nv3dsink again it will start streaming of cameras but it’ll be blank/corrupted screen.

Now the main thing here is whenever I face this issue and reboot the board it’ll Be capturing video properly whether using nv3dsink or filesink… But only for the first iteration.

So my basic question here is what is the issue with filesink or fakesink that if i run them it is making the cameras corrupted.. Because if i run nv3dsink multiple times it’ll work properly. but just after filesink or fakesink that too will stop working.

We are not observing any crashes.. just the black/corrupted video stream.

I have also tried this command “sudo systemctl restart nvargus-daemon.service” But the observations remains same…

Thanks.

What’s the command for those steps?

For nv3dsink we use “gst-launch-1.0 -v nvarguscamerasrc sensor-id=0 sensor-mode=0 ! nv3dsinksink”
for fakesink “gst-launch-1.0 -v nvarguscamerasrc sensor-id=0 sensor-mode=0 ! fakesink”
and for filesink " gst-launch-1.0 -v nvarguscamerasrc sensor-id=0 sensor-mode=0 ! ‘video/x-raw(memory:NVMM),format=NV12,width=3856,height=2180’ ! nvv4l2h264enc bitrate=8000000 ! h264parse ! qtmux ! filesink location=case_6_9.mp4 -e"

Sensor id 0 & 1 we are running in parellel…

You can have & to add another camera by different sensor-id to launch multiple cameras.
For example

gst-launch-1.0 -v nvarguscamerasrc sensor-id=0 sensor-mode=0 ! fakesink & gst-launch-1.0 -v nvarguscamerasrc sensor-id=1 sensor-mode=0 ! fakesink

Yes we are doing that in parallel for sensor id 0 and 1.
I have pasted only 1 sensor id command for your reference second camera id command will be the same just sensor id will be 0.

And also we are running these cameras in master slave mode… sensor id 1 is master and 0 is slave.

The main Question for here is does fakesink or filesink cause any disruptions on GStream pipelines ?
Because we are observing such behavior here

Didn’t hear this kind of case.
Maybe boost the clocks to try.

sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee  /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate

I have checked using this… But there is no improvement.

If I use any sink it’ll just work for the first time only after reboot.. after that nothing is working.
Can someone confirm it is the usual behaviour of nvidia sinks or something else ?

Please Help.
Thanks.

Hi, I have some questions that might help better understand the problem

  1. Does this issue appear when using only one camera?
  2. Is the issue happening on both cameras at the same time?
  3. Do you know if the camera is still sending buffers when the error happens?

You could also check if theres is something strange happening on the GStreamer pipeline if you change the debug level:

GST_DEBUG=*:4  gst-launch-1.0 -v nvarguscamerasrc sensor-id=0 sensor-mode=0 ! nv3dsinksink

Didn’t hear any sink would cause this kind of problem.
Do you verify the v4l2-ctl open/close stress test?

Hi, Sure I’ll try with the changed debug level that you’re suggesting.

And to answer your questions…

  1. Does this issue appear when using only one camera?
    Answer : We are using 2 cameras directly in master slave mode.
  2. Is the issue happening on both cameras at the same time?
    Answer : Yes While running them parellely
  3. Do you know if the camera is still sending buffers when the error happens?
    Answer : I am getting only these logs which I am attaching below :

Logs: these are for sensor id 0 and I am having the same logs for sensor id 1
gst-launch-1.0 -v nvarguscamerasrc sensor-id=0 sensor-mode=0 ! nv3dsink
Setting pipeline to PAUSED …
Pipeline is live and does not need PREROLL …
Setting pipeline to PLAYING …
New clock: GstSystemClock
/GstPipeline:pipeline0/GstNvArgusCameraSrc:nvarguscamerasrc0.GstPad:src: caps = video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080, format=(string)NV12, framerate=(fraction)30/1
/GstPipeline:pipeline0/GstNv3dSink:nv3dsink0.GstPad:sink: caps = video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080, format=(string)NV12, framerate=(fraction)30/1
GST_ARGUS: Creating output stream
CONSUMER: Waiting until producer is connected…
GST_ARGUS: Available Sensor modes :
GST_ARGUS: 3856 x 2180 FR = 59.999999 fps Duration = 16666667 ; Analog Gain range min 1.000000, max 3981.070801; Exposure Range min 27000, max 660000000;

GST_ARGUS: 2608 x 1964 FR = 66.000001 fps Duration = 15151515 ; Analog Gain range min 1.000000, max 3981.070801; Exposure Range min 27000, max 660000000;

GST_ARGUS: 1920 x 1080 FR = 116.999994 fps Duration = 8547009 ; Analog Gain range min 1.000000, max 3981.070801; Exposure Range min 27000, max 660000000;

GST_ARGUS: 1928 x 1090 FR = 59.999999 fps Duration = 16666667 ; Analog Gain range min 1.000000, max 3981.070801; Exposure Range min 27000, max 660000000;

GST_ARGUS: 3856 x 2180 FR = 71.999999 fps Duration = 13888889 ; Analog Gain range min 1.000000, max 3981.070801; Exposure Range min 27000, max 660000000;

GST_ARGUS: 2608 x 1964 FR = 78.999999 fps Duration = 12658228 ; Analog Gain range min 1.000000, max 3981.070801; Exposure Range min 27000, max 660000000;

GST_ARGUS: 1920 x 1080 FR = 140.000003 fps Duration = 7142857 ; Analog Gain range min 1.000000, max 3981.070801; Exposure Range min 27000, max 660000000;

GST_ARGUS: Running with following settings:
Camera index = 0
Camera mode = 0
Output Stream W = 3856 H = 2180
seconds to Run = 0
Frame Rate = 59.999999
GST_ARGUS: Setup Complete, Starting captures for 0 seconds
GST_ARGUS: Starting repeat capture requests.
CONSUMER: Producer has connected; continuing.
WARNING: from element /GstPipeline:pipeline0/GstNv3dSink:nv3dsink0: Pipeline construction is invalid, please add queues.
Additional debug info:
gstbasesink.c(1209): gst_base_sink_query_latency (): /GstPipeline:pipeline0/GstNv3dSink:nv3dsink0:
Not enough buffering available for the processing deadline of 0:00:00.015000000, add enough queues to buffer 0:00:00.015000000 additional data. Shortening processing latency to 0:00:00.000000000.
^Chandling interrupt.
Interrupt: Stopping pipeline …
Execution ended after 0:00:05.179430129
Setting pipeline to NULL …
GST_ARGUS: Cleaning up
CONSUMER: Done Success
GST_ARGUS: Done Success
Freeing pipeline …

Add queue to try.

gst-launch-1.0 -v nvarguscamerasrc sensor-id=0 sensor-mode=0 ! queue ! nv3dsink

Done this also but it didn’t work..

Does single camera have the problem?

No when I reboot the device both camera can stream in parallel for nv3dsink and filesink but when I end that stream and again start the stream It’ll not work It’ll show me black/corrupted screen. And we are running this in master slave mode.

What I want to clarify is open master only without problem?

when we open master only it is having the same problem.

Regarding the reboot issue, you can find a way to get more logs from nvargus-daemon here:

essentially following these instructions to get more logs and plugging into AI tools:

To enable logs from user-space for more details

sudo service nvargus-daemon stop
sudo su
export enableCamPclLogs=5
export enableCamScfLogs=5
/usr/sbin/nvargus-daemon

launch camera from another console

Verify the sensor streaming by v4l2-ctl like below to confirm the sensor control.

while 1
    v4l2-ctl -c bypass_mode=0 --stream-mmap --stream-count=100 -d /dev/video0
    v4l2-ctl -c bypass_mode=0 --stream-mmap --stream-count=100 -d /dev/video1
    sleep 2
done