This is a follow up from this post. Since getting camera data using a BufferedOutputStream avoids a copy to an EGL stream, which FrameConsumer does not avoid, I was expecting to see a lower CPU usage from nvargus-daemon when using the BufferedOutputStream approach. I attached two test programs which get 1MP images from the camera at 60 hz using the two different methods. In both cases, the CPU usage from nvargus-daemon was around 45% of one core (7.5% of all 6 cores as measured with Irix mode disabled).
I also tried setting aelock and awblock using AutoControlSettings since the post also mentioned that these algorithms use CPU. In this case, nvargus-daemon used around 1% less CPU with Irix mode enabled (with Irix mode disabled the difference in CPU usage was too small to see).
Copying to EGL streams and the ae and awb algorithms don’t seem to be the main causes of the CPU usage in nvargus-daemon. I’m mainly concerned about the CPU usage because when running 6 cameras at 1MP 60Hz almost 3 of the 6 cores are used by nvargus-daemon which leaves half of the CPU resources for applications using the images.
I have a few questions:
Do you know what the cause of the nvargus-daemon CPU usage is?
Are there are any plans to release the source code?
Are there any resources about bypassing nvargus-daemon and reading the camera data directly?
we don’t have plan to release the source code.
you may try v4l2 standard control to fetch camera raw files, this bypass the internal camera core.
for example, v4l2-ctl -d /dev/video0 --set-fmt-video=width=2592,height=1944,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=test.raw
Thanks for the fast reply. I tried the v4l2-ctl command you mentioned and also modified it to use--set-fmt-video=width=1224,height=1028,pixelformat=RG12based on the output of v4l2-ctl --all --device /dev/video0. The process hangs and I’m not able to kill it, even by doing kill -9 <pid of v4l2-ctl>, and I’m not able to access the camera through any method until I restart the xavier. Do you know what might cause this?
is this camera driver validate before? it’s the V4L2 IOCTL to verify basic camera functionality,
please also share the failure reported from kernel side, i.e. $ dmesg > klog.txt
thanks
Hi Jerry,
Yes the camera driver has been validated. Using gstreamer and the argus samples in jetson_multimedia_api work with the cameras. I attached the output of dmesg.
there’re discarding frame logs, those capture frames has been dropped;
the error flag indicate that capture channel has encountered uncorrectable error and it must be reset.
could you please add set_mode_delay_ms in the mode settings, please add wait time for the first frame after capture starts, the unit is in milliseconds.