I’m curious if a performance bottleneck we are seeing with nvvidconv is expected or not.
We have six cameras and are running six gstreamer pipelines in our application that look like:
nvcamerasrc sensor-id=X fpsRange="30 30" ! "video/x-raw(memory:NVMM), width=(int)1280, height=(int)1080, format=(string)I420, framerate=(fraction)30/1" ! nvvidconv ! "video/x-raw, width=(int)1280, height=(int)1080, format=(string)I420, framerate=(fraction)30/1" ! appsink
With all six cameras running, we are only getting ~20-21 fps. That’s doing nothing but pulling samples in the appsink callback. However, with a pipeline that stays in NVMM memory (for example recording with omxh264enc), all six cameras are able to stream at 30fps.
Interestingly, if I have nvvidconv resize the images to half size:
nvcamerasrc sensor-id=X fpsRange="30 30" ! "video/x-raw(memory:NVMM), width=(int)1280, height=(int)1080, format=(string)I420, framerate=(fraction)30/1" ! nvvidconv ! "video/x-raw, width=(int)640, height=(int)540, format=(string)I420, framerate=(fraction)30/1" ! appsink
Then our application receives frames at 30fps in the appsink callbacks. Running only 4 cameras instead of all 6 also results in 30fps (at full res) in the appsink callbacks. This seems like it’s an issue with the nvmm to cpu buffer conversion overhead.
Should converting 6 1280x1080 streams at 30fps be possible with nvvidconv? If not, is there an alternative method we should try?