I have recently noticed that the system load average while capturing frames on the Jetson Nano over CSI is unusually high (individual CPU load tends to remain low).
In order to rule out if this was something specific to my design, I ran a few tests on a Jetson Nano Devkit rev a02 with a single imx219 and Jetpack 4.4 (r32.4.2).
My first test was to capture video and send it nowhere using v4l2-ctl.
The commands for this test are the following:
v4l2-ctl -d /dev/video0 -c sensor_mode=2 --set-fmt-video=width=1920,height=1080,pixelformat=“RG10”
v4l2-ctl -d /dev/video0 -c gain=170 -c override_enable=1 -c bypass_mode=0 -c exposure=33333 -c frame_rate=30000000
v4l2-ctl -d /dev/video0 --stream-skip=100 --stream-count=120 --stream-mmap
For this test, the system load stabilizes around 1 after a while (more than 15 minutes).
For the second test, I decided to use gstreamer with nvargussrc.
The command for this one is the following one
gst-launch-1.0 nvarguscamerasrc ! ‘video/x-raw(memory:NVMM), format=NV12, width=1920, height=1080, framerate=30/1’ ! fakesink
For this test, the system load is a more conservative 0.45, with some spikes.
As a third test, we made v4l2-ctl capture a single video stream on our custom designed board and the load once again stabilized around 1.
As a fourth and final test, we made v4l2-ctl capture two video streams on two different cameras using the same custom board, with the load climbing to 2.
From the last two tests, it looks like the load scales linearly with the amount of cameras used.
The problem is, this product is supposed to support four CSI cameras and still be able to do something with them.
At best, this looks like a bug (at least on v4l2) and I’m really surprised no one seems to be bothered.
At worst, this means like I might have to throw away all the time spent working on the Jetson Nano and loose a lot of potential clients.
I hope there is some kind of solution for this issue.