The nvarguscamerasrc plugin is Frame loss

Autonomous Machines Jetson & Embedded Systems Jetson AGX Orin
1

Frames are dropped when I use the following command

GST_DEBUG_DUMP_DOT_DIR=/media/Data/log gst-launch-1.0 nvcompositor name=comp sink_0::xpos=0 sink_0::ypos=0 sink_0::width=960 sink_0::height=540         sink_1::xpos=960 sink_1::ypos=0 sink_1::width=960 sink_1::height=540         sink_2::xpos=0 sink_2::ypos=540 sink_2::width=960 sink_2::height=540         sink_3::xpos=960 sink_3::ypos=540 sink_3::width=960 sink_3::height=540         ! nvvidconv ! 'video/x-raw(memory:NVMM),width=1920,height=1080,format=NV12,framerate=10/1' ! nvv4l2h264enc bitrate=$bitrate_preview ! h264parse ! flvmux ! rtmpsink blocksize=24834048  location='rtmp://127.0.0.1/live/mux4'         nvarguscamerasrc sensor-id=0 wbmode=0 ee-mode=0 saturation=0 blocksize=99336192 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam0 !        queue !  nvvidconv  ! "video/x-raw(memory:NVMM), width=2064, height=1504, format=(string)NV12" !  nvvidconv  ! "video/x-raw" !  multifilesink max-file-size=1862553600  next-file=4 blocksize=4096 location=$FILE_HOME_DIR/$TIMESTAMPS-cam0_%04d.nv12 -e cam0. ! queue ! comp.sink_0 cam0. ! queue !   nvvidconv ! 'video/x-raw(memory:NVMM),width=3840,height=2160,format=NV12,framerate=10/1' ! nvv4l2h265enc bitrate=$shutter_record capture-io-mode=2 maxperf-enable=true ! h265parse ! mp4mux ! filesink location=$FILE_HOME_DIR/$TIMESTAMPS-cam-0.mp4         nvarguscamerasrc sensor-id=1 wbmode=0 ee-mode=0 saturation=0 blocksize=99336192 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam1 !         queue !  nvvidconv  ! "video/x-raw(memory:NVMM), width=2064, height=1504, format=(string)NV12" !  nvvidconv  ! "video/x-raw" !  multifilesink max-file-size=1862553600  next-file=4 blocksize=4096 location=$FILE_HOME_DIR/$TIMESTAMPS-cam1_%04d.nv12 -e cam1. ! queue ! comp.sink_1  cam1. ! queue !   nvvidconv ! 'video/x-raw(memory:NVMM),width=3840,height=2160,format=NV12,framerate=10/1'  ! nvv4l2h265enc bitrate=$shutter_record capture-io-mode=2 maxperf-enable=true ! h265parse ! mp4mux ! filesink location=$FILE_HOME_DIR/$TIMESTAMPS-cam-1.mp4         nvarguscamerasrc sensor-id=2 wbmode=0 ee-mode=0 saturation=0 blocksize=99336192 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam2 !        queue !  nvvidconv  ! "video/x-raw(memory:NVMM), width=2064, height=1504, format=(string)NV12" !  nvvidconv  ! "video/x-raw" !  multifilesink max-file-size=1862553600  next-file=4 blocksize=4096 location=$FILE_HOME_DIR/$TIMESTAMPS-cam2_%04d.nv12 -e cam2. ! queue ! comp.sink_2  cam2. ! queue !   nvvidconv ! 'video/x-raw(memory:NVMM),width=3840,height=2160,format=NV12,framerate=10/1' ! nvv4l2h265enc bitrate=$shutter_record capture-io-mode=2 maxperf-enable=true ! h265parse ! mp4mux ! filesink location=$FILE_HOME_DIR/$TIMESTAMPS-cam-2.mp4         nvarguscamerasrc sensor-id=3 wbmode=0 ee-mode=0 saturation=0 blocksize=99336192 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam3 !        queue !  nvvidconv  ! "video/x-raw(memory:NVMM), width=2064, height=1504, format=(string)NV12" !  nvvidconv  ! "video/x-raw" !  multifilesink max-file-size=1862553600  next-file=4 blocksize=4096 location=$FILE_HOME_DIR/$TIMESTAMPS-cam3_%04d.nv12 -e cam3. ! queue ! comp.sink_3  cam3. ! queue !   nvvidconv ! 'video/x-raw(memory:NVMM),width=3840,height=2160,format=NV12,framerate=10/1'  ! nvv4l2h265enc bitrate=$shutter_record capture-io-mode=2 maxperf-enable=true ! h265parse ! mp4mux ! filesink location=$FILE_HOME_DIR/$TIMESTAMPS-cam-3.mp4

The printed log is as follows:

Acquired Frame: 1948, time sec 194 msec 71 id:281469658321376 timespace:29276500356000
Acquired Frame: 1948, time sec 194 msec 87 id:281469633143264 timespace:29276516196000
Acquired Frame: 1948, time sec 194 msec 122 id:281469885997536 timespace:29276551058000
Acquired Frame: 1948, time sec 194 msec 134 id:281469911175648 timespace:29276563934000
Acquired Frame: 1949, time sec 194 msec 171 id:281469658321376 timespace:29276600769000
Acquired Frame: 1949, time sec 194 msec 223 id:281469633143264 timespace:29276652740000
Acquired Frame: 1949, time sec 194 msec 264 id:281469885997536 timespace:29276693542000
Acquired Frame: 1950, time sec 194 msec 310 id:281469911175648 timespace:29276739808000
Acquired Frame: 1950, time sec 194 msec 359 id:281469658321376 timespace:29276788765000
Acquired Frame: 1951, time sec 194 msec 402 id:281469633143264 timespace:29276831663000
Acquired Frame: 1951, time sec 194 msec 450 id:281469885997536 timespace:29276879199000
Acquired Frame: 1952, time sec 194 msec 492 id:281469911175648 timespace:29276921962000
Acquired Frame: 1952, time sec 194 msec 545 id:281469658321376 timespace:29276974531000
Acquired Frame: 1953, time sec 194 msec 588 id:281469633143264 timespace:29277017273000
Acquired Frame: 1953, time sec 194 msec 635 id:281469885997536 timespace:29277064990000
Acquired Frame: 1954, time sec 194 msec 673 id:281469911175648 timespace:29277103013000
Acquired Frame: 1954, time sec 194 msec 690 id:281469658321376 timespace:29277119922000
Acquired Frame: 1954, time sec 194 msec 722 id:281469633143264 timespace:29277151977000
Acquired Frame: 1954, time sec 194 msec 756 id:281469885997536 timespace:29277185281000

Then I found in the process of debugging that the entire function below did not respond.From the log, we can see that the frame number has been accumulating, indicating that this frame has been accepted at the bottom level, but I do not know why it was discarded, and dmesg has no discarded log information, I want to know where the source code of the bottom level of the frame number is accumulated? I need to investigate this issue further.

iEventProvider_ptr->waitForEvents(src->queue.get(), WAIT_FOR_EVENT_TIMEOUT);
3

hello 1508723374,

it doesn’t looks correct to acquire several frames with the same frame-id.
for example,

you may also examine the sensor outputting frame-rates.
could you please give it a try to disable preview and shows frame-rate only.
for instance,
$ gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! 'video/x-raw(memory:NVMM),width=1920, height=1080, framerate=30/1, format=NV12' ! nvvidconv ! 'video/x-raw(memory:NVMM),format=I420' ! fpsdisplaysink text-overlay=0 video-sink=fakesink sync=0 -v

FYI,
there’re a set of EventTypes, it’s waitForEvents to wait for internal event types in the queue.
you may see-also Argus::IEventQueue, and also Event.h for Core Event types.

4

I don’t know what time stands for here, but it looks like the three frames 1949 are synchronized.

If only the frame rate is displayed or the four-way MP4 encoding part is removed, no frames are dropped.

gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! ‘video/x-raw(memory:NVMM),width=4128, height=3008, framerate=10/1, format=NV12’ ! nvvidconv ! ‘video/x-raw(memory:NVMM),format=I420’ ! fpsdisplaysink text-overlay=0 video-sink=fakesink sync=1 -v nvarguscamerasrc sensor-id=1 ! ‘video/x-raw(memory:NVMM),width=4128, height=3008, framerate=10/1, format=NV12’ ! nvvidconv ! ‘video/x-raw(memory:NVMM),format=I420’ ! fpsdisplaysink text-overlay=0 video-sink=fakesink sync=1 -v nvarguscamerasrc sensor-id=2 ! ‘video/x-raw(memory:NVMM),width=4128, height=3008, framerate=10/1, format=NV12’ ! nvvidconv ! ‘video/x-raw(memory:NVMM),format=I420’ ! fpsdisplaysink text-overlay=0 video-sink=fakesink sync=1 -v nvarguscamerasrc sensor-id=3 ! ‘video/x-raw(memory:NVMM),width=4128, height=3008, framerate=10/1, format=NV12’ ! nvvidconv ! ‘video/x-raw(memory:NVMM),format=I420’ ! fpsdisplaysink text-overlay=0 video-sink=fakesink sync=1 -v

GST_DEBUG_DUMP_DOT_DIR=/media/Data/log gst-launch-1.0 nvcompositor name=comp sink_0::xpos=0 sink_0::ypos=0 sink_0::width=960 sink_0::height=540         sink_1::xpos=960 sink_1::ypos=0 sink_1::width=960 sink_1::height=540         sink_2::xpos=0 sink_2::ypos=540 sink_2::width=960 sink_2::height=540         sink_3::xpos=960 sink_3::ypos=540 sink_3::width=960 sink_3::height=540         ! nvvidconv ! 'video/x-raw(memory:NVMM),width=1920,height=1080,format=NV12,framerate=10/1' ! nvv4l2h264enc bitrate=4000000 ! h264parse ! flvmux ! rtmpsink blocksize=24834048  location='rtmp://127.0.0.1/live/mux4'         nvarguscamerasrc sensor-id=0 wbmode=0 ee-mode=0 saturation=0 blocksize=99336192 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam0 !        queue !  nvvidconv  ! "video/x-raw(memory:NVMM), width=2064, height=1504, format=(string)NV12" !  nvvidconv  ! "video/x-raw" !  multifilesink max-file-size=1396915200 next-file=4 blocksize=40960 location=cam0_%04d.nv12 -e cam0. ! queue ! comp.sink_0     nvarguscamerasrc sensor-id=1 wbmode=0 ee-mode=0 saturation=0 blocksize=99336192 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam1 !         queue !  nvvidconv  ! "video/x-raw(memory:NVMM), width=2064, height=1504, format=(string)NV12" !  nvvidconv  ! "video/x-raw" !  multifilesink max-file-size=1396915200 next-file=4 blocksize=40960 location=cam1_%04d.nv12 -e cam1. ! queue ! comp.sink_1         nvarguscamerasrc sensor-id=2 wbmode=0 ee-mode=0 saturation=0 blocksize=99336192 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam2 !        queue !  nvvidconv  ! "video/x-raw(memory:NVMM), width=2064, height=1504, format=(string)NV12" !  nvvidconv  ! "video/x-raw" !  multifilesink max-file-size=1396915200 next-file=4 blocksize=40960 location=cam2_%04d.nv12 -e cam2. ! queue ! comp.sink_2          nvarguscamerasrc sensor-id=3 wbmode=0 ee-mode=0 saturation=0 blocksize=99336192 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam3 !        queue !  nvvidconv  ! "video/x-raw(memory:NVMM), width=2064, height=1504, format=(string)NV12" !  nvvidconv  ! "video/x-raw" !  multifilesink max-file-size=1396915200 next-file=4 blocksize=40960 location=cam3_%04d.nv12 -e cam3. ! queue ! comp.sink_3
5

hello 1508723374,

may I also know what’s the environment setup for your camera hardware connections.
for instance,
is there hardware sync pin connected?
do you have multi-cam synchornization use-case?
how cameras are running simultaneously?

6

My platform is jeston AGX orin developer kit. I customize a 120pin adapter board to connect four lenses. The lenses work in trig mode, adopt hardware synchronization scheme, use external MCU to output a constant 10HZ trigger signal, and divide the signal into four to four lenses.By measuring the signal with the oscilloscope, I was able to determine that the trigger signal was OK

7

you may refer to Argus sample, syncSensor. it should able to support up-to four camera in single session.

8

You mean reference 13_argus_multi_camera. If this scheme is adopted, it means that I need to start from scratch to explore. The current project cycle does not support me to start from scratch, but I still hope to realize this function through this command line method. Can you help me solve the problem from this direction?

9

hello 1508723374,

no, 13_argus_multi_camera it doesn’t demonstrate the synchronization mechanism.
I meant the Argus sample app, syncSensor.
you may download MMAPI, $ sudo apt install nvidia-l4t-jetson-multimedia-api
it should be available by checking… /jetson_multimedia_api/argus/samples/syncSensor

your gst pipeline doesn’t have software sync mechanism, it duplicate threads to keep fetching the frames.
anyways, you may give it a try to configure waiting time for the acquireFrame/event before timeout.
for instance,
acquire-wait, default is 5000000000 (units in nanosec)
event-wait, default 3000000000 (units in nanosec)
here’s a sample pipeline to increase timeout values for acquireFrame/event wait.
$ gst-launch-1.0 -v nvarguscamerasrc event-wait=5000000000 acquire-wait=6000000000 sensor-id=0 ! video/x-raw(memory:NVMM),format=NV12,width=1824,height=940,framerate=60/1 ! nvvidconv ! fakesink -e

11

I have started to debug the nvarguscamerasrc plug-in. During the debugging, I found some asynchronies. I think there may be some bugs in this plug-in.Below is my debug source code and log, you can have a look, help me analyze the problem.The problem shown in the screenshot is that the print information in the log is inconsistent between the consumer_thread and threadExecute threads.
test.zip (270.2 KB)

image
image870×434 41.5 KB

And then the command that my program runs is this:

GST_DEBUG_DUMP_DOT_DIR=/media/Data/log gst-launch-1.0 nvcompositor name=comp sink_0::xpos=0 sink_0::ypos=0 sink_0::width=960 sink_0::height=540         sink_1::xpos=960 sink_1::ypos=0 sink_1::width=960 sink_1::height=540         sink_2::xpos=0 sink_2::ypos=540 sink_2::width=960 sink_2::height=540         sink_3::xpos=960 sink_3::ypos=540 sink_3::width=960 sink_3::height=540         ! nvvidconv interpolation-method=4 ! 'video/x-raw(memory:NVMM),width=1920,height=1080,format=NV12,framerate=10/1' ! nvv4l2h264enc iframeinterval=10 insert-sps-pps=true bitrate=$bitrate_preview ! h264parse ! flvmux ! rtmpsink blocksize=24834048  location='rtmp://127.0.0.1/live/mux4'         nvarguscamerasrc sensor-id=0 wbmode=0 ee-mode=0 saturation=0 blocksize=248340480 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam0  ! queue ! comp.sink_0       nvarguscamerasrc sensor-id=1 wbmode=0 ee-mode=0 saturation=0 blocksize=248340480 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam1 !         queue  !  nvvidconv  ! "video/x-raw"  !  multifilesink max-file-size=1862553600  next-file=4 blocksize=4096 location=$FILE_HOME_DIR/cam1-%04d.nv12 -e cam1. ! queue ! comp.sink_1  cam1. ! queue !   nvvidconv ! 'video/x-raw(memory:NVMM),width=3840,height=2160,format=NV12,framerate=10/1'  ! nvv4l2h265enc bitrate=$shutter_record capture-io-mode=2 maxperf-enable=true ! h265parse ! mp4mux ! filesink location=$FILE_HOME_DIR/cam-1.mp4         nvarguscamerasrc sensor-id=2 wbmode=0 ee-mode=0 saturation=0 blocksize=248340480 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam2 !        queue !  nvvidconv  ! "video/x-raw" !  multifilesink max-file-size=1862553600  next-file=4 blocksize=4096 location=$FILE_HOME_DIR/cam2-%04d.nv12 -e cam2. ! queue ! comp.sink_2  cam2. ! queue !   nvvidconv ! 'video/x-raw(memory:NVMM),width=3840,height=2160,format=NV12,framerate=10/1' ! nvv4l2h265enc bitrate=$shutter_record capture-io-mode=2 maxperf-enable=true ! h265parse ! mp4mux ! filesink location=$FILE_HOME_DIR/cam-2.mp4         nvarguscamerasrc sensor-id=3 wbmode=0 ee-mode=0 saturation=0 blocksize=248340480 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam3  ! queue ! comp.sink_3   > /media/Data/$TIMESTAMPS/frame_time.txt  &

The odd thing is that I didn’t have any problems using the following command, I think there was a problem when the data was converted in the middle. Can you tell me why these phenomena occur?

GST_DEBUG_DUMP_DOT_DIR=/media/Data/log gst-launch-1.0 nvcompositor name=comp sink_0::xpos=0 sink_0::ypos=0 sink_0::width=960 sink_0::height=540         sink_1::xpos=960 sink_1::ypos=0 sink_1::width=960 sink_1::height=540         sink_2::xpos=0 sink_2::ypos=540 sink_2::width=960 sink_2::height=540         sink_3::xpos=960 sink_3::ypos=540 sink_3::width=960 sink_3::height=540         ! nvvidconv interpolation-method=4 ! 'video/x-raw(memory:NVMM),width=1920,height=1080,format=NV12,framerate=10/1' ! nvv4l2h264enc iframeinterval=10 insert-sps-pps=true bitrate=$bitrate_preview ! h264parse ! flvmux ! rtmpsink blocksize=24834048  location='rtmp://127.0.0.1/live/mux4'         nvarguscamerasrc sensor-id=0 wbmode=0 ee-mode=0 saturation=0 blocksize=248340480 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam0  ! queue ! comp.sink_0       nvarguscamerasrc sensor-id=1 wbmode=0 ee-mode=0 saturation=0 blocksize=248340480 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam1 !   queue ! comp.sink_1  cam1. ! queue !   nvvidconv ! 'video/x-raw(memory:NVMM),width=3840,height=2160,format=NV12,framerate=10/1'  ! nvv4l2h265enc bitrate=$shutter_record capture-io-mode=2 maxperf-enable=true ! h265parse ! mp4mux ! filesink location=$FILE_HOME_DIR/cam-1.mp4         nvarguscamerasrc sensor-id=2 wbmode=0 ee-mode=0 saturation=0 blocksize=248340480 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam2 !  queue ! comp.sink_2  cam2. ! queue !   nvvidconv ! 'video/x-raw(memory:NVMM),width=3840,height=2160,format=NV12,framerate=10/1' ! nvv4l2h265enc bitrate=$shutter_record capture-io-mode=2 maxperf-enable=true ! h265parse ! mp4mux ! filesink location=$FILE_HOME_DIR/cam-2.mp4         nvarguscamerasrc sensor-id=3 wbmode=0 ee-mode=0 saturation=0 blocksize=248340480 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam3  ! queue ! comp.sink_3   > /media/Data/$TIMESTAMPS/frame_time.txt  &
14

Hi,
The performance bottleneck should be saving frame data to file. The file I/O may slow down the whole pipeline. Please remove saving to a file from the pipeline and give it a try.

For optimal throughput of AGX Orin, please execute the script:
VPI - Vision Programming Interface: Performance Benchmark

15

The above reply is the result of using this script, which I found in another header. Is there any solution to improve file I/O performance?

16

Hi,
The bottleneck is in

... !  nvvidconv  ! "video/x-raw" ! multifilesink max-file-size=1862553600  next-file=4 blocksize=4096 location=$FILE_HOME_DIR/$TIMESTAMPS-cam0_%04d.nv12
... !  nvvidconv  ! "video/x-raw" ! multifilesink max-file-size=1862553600  next-file=4 blocksize=4096 location=$FILE_HOME_DIR/$TIMESTAMPS-cam2_%04d.nv12

Would suggest remove them.

17

Our project needs two data, one needs the original data NV12, which will be used by the algorithm, and the other is MP4, which will view the captured data.

18

Hi,
It is fine to do it for debugging purpose. But it is bottleneck of whole pipeline and we suggest remove it in actual use-case.

19

Do you mean that NVMM memory I/O line performance is limited?

20

Hi,
No, using NVMM buffers in the whole pipeline is an optimal solution. For saving frame data to a file, the data has to be copied from NVMM buffer to CPU buffer, and save to a file. These are additional operations and slow down the whole pipeline.

21

How do I know if the NVMM copy to CPU performance is limited or save to file performance is limited. In the process of running the program, the CPU usage is about 58%, and the disk write data size is 350M/s, which does not seem to reach their maximum performance.

cfc20f5565e0f767d1f261f3c732d05
cfc20f5565e0f767d1f261f3c732d052846×1280 363 KB

image
image2130×333 15 KB

22

Hi,
You can break down the pipeline to check further. Saving YUV/NV12 data to storage should take significant system loading.

23

I reduced the resolution on the basis of the original command, and the write speed was reduced from the original 350M/s to 100M/s, or the phenomenon in the following screenshot.

GST_DEBUG_DUMP_DOT_DIR=/media/Data/log gst-launch-1.0 nvcompositor name=comp sink_0::xpos=0 sink_0::ypos=0 sink_0::width=960 sink_0::height=540         sink_1::xpos=960 sink_1::ypos=0 sink_1::width=960 sink_1::height=540         sink_2::xpos=0 sink_2::ypos=540 sink_2::width=960 sink_2::height=540         sink_3::xpos=960 sink_3::ypos=540 sink_3::width=960 sink_3::height=540         ! nvvidconv interpolation-method=4 ! 'video/x-raw(memory:NVMM),width=1920,height=1080,format=NV12,framerate=10/1' ! nvv4l2h264enc iframeinterval=10 insert-sps-pps=true bitrate=$bitrate_preview ! h264parse ! flvmux ! rtmpsink blocksize=24834048  location='rtmp://127.0.0.1/live/mux4'         nvarguscamerasrc sensor-id=0 wbmode=0 ee-mode=0 saturation=0 blocksize=248340480 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam0  ! queue ! comp.sink_0       nvarguscamerasrc sensor-id=1 wbmode=0 ee-mode=0 saturation=0 blocksize=248340480 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam1 !    queue !  nvvidconv  ! "video/x-raw(memory:NVMM), width=2064, height=1504, format=(string)NV12" !     nvvidconv  ! "video/x-raw"  !  multifilesink max-file-size=1862553600  next-file=4 blocksize=40960 location=$FILE_HOME_DIR/cam1-%04d.nv12 -e cam1. ! queue ! comp.sink_1  cam1. ! queue !   nvvidconv ! 'video/x-raw(memory:NVMM),width=3840,height=2160,format=NV12,framerate=10/1'  ! nvv4l2h265enc bitrate=$shutter_record  ! h265parse ! mp4mux ! filesink location=$FILE_HOME_DIR/cam-1.mp4         nvarguscamerasrc sensor-id=2 wbmode=0 ee-mode=0 saturation=0 blocksize=248340480 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam2 !   queue !  nvvidconv  ! "video/x-raw(memory:NVMM), width=2064, height=1504, format=(string)NV12"    !  nvvidconv  ! "video/x-raw" !  multifilesink max-file-size=1862553600  next-file=4 blocksize=40960 location=$FILE_HOME_DIR/cam2-%04d.nv12 -e cam2. ! queue ! comp.sink_2  cam2. ! queue !   nvvidconv ! 'video/x-raw(memory:NVMM),width=3840,height=2160,format=NV12,framerate=10/1' ! nvv4l2h265enc bitrate=$shutter_record  ! h265parse ! mp4mux ! filesink location=$FILE_HOME_DIR/cam-2.mp4         nvarguscamerasrc sensor-id=3 wbmode=0 ee-mode=0 saturation=0 blocksize=248340480 ! 'video/x-raw(memory:NVMM), width=(int)4128, height=(int)3008,format=(string)NV12, framerate=(fraction)10/1' ! tee name=cam3  ! queue ! comp.sink_3   > /media/Data/$TIMESTAMPS/frame_time.txt  &

image
image1032×781 71.4 KB

24

hallo，DaneLLL
When debugging the underlying driver, I found that NvBufSurfaceFromFd sometimes takes 50~70ms, which will lead to acquireFrame stagnation. May I ask why?