GStreamer Application with ZED Mini using nvvidconv on Nano

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

Hi all,

I am currently working on understanding the gstreamer applications at a low level (hardware impacts and optimized pipelines). When working with ZED camera, I see that CPU utilization of Jetson is greater than it is when working with any other camera. I wonder what causes this since ZED camera outputs one merged frame that is obtained from dual cameras.

My second question is what is the difference between two commands below? First one provides 60 fps when the other one provides 45 fps? Is there any extra memcpy that comes from extra memory:NVMM usage?

gst-launch-1.0 v4l2src device=/dev/video1 ! 'video/x-raw, width=2560, height=720, format=YUY2, framerate=60/1' ! nvvidconv ! 'video/x-raw, format=YUY2' ! nvvidconv ! 'video/x-raw, format=YUY2' ! fpsdisplaysink name=fpssink text-overlay=true video-sink=xvimagesink signal-fps-measurements=true sync=false -v

gst-launch-1.0 v4l2src device=/dev/video1 ! 'video/x-raw, width=2560, height=720, format=YUY2, framerate=60/1' ! nvvidconv ! 'video/x-raw(memory:NVMM), format=YUY2' ! nvvidconv ! 'video/x-raw, format=YUY2' ! fpsdisplaysink name=fpssink text-overlay=true video-sink=xvimagesink signal-fps-measurements=true sync=false -v

Thanks in advance.

2

Hi,
You are right, transferring buffers from NVMM memory to normal memory always involves a copy. On the second pipeline you have 2 additional memcpy (one from normal memory to NVMM and another back to normal memory). The elements you are using (v4l2src and xvimagesink) use normal memory. There is no point on using NVMM unless you are using accelerated elements that consume/produce NVMM, like nvoverlaysink, nvarguscamerasrc, …

As a side note, I was glad to find out that nvvidconv now supports conversions from normal memory to normal memory. In the past only NVMM-NVMM, NVMM-normal and normal-NVMM conversions were supported.

3

Thank you for the explanation.