I have connected an IMX219 Raspberry Camera to my Jetson Nano, and am trying to access the camera from my code using V4L2. I can access via libargus, but would ideally like to avoid having an extra daemon running, as I have found Argus to often get itself into a bad state requiring daemon restart, and read elsewhere that it tends to consume lots of memory.
The v4l2cuda samples is not designed for raw capture.
We are suggest using nvarguscamerasrc and argus_camera to run on imx219.
nvarguscamerasrc pipeline:
I am trying argus, but the only example I found so far that does zero-copy to CUDA is the Histogram one that is luminance only. Is there source code available, so I can see how Argus uses V4L2?
My Jetson SDcard image did not have that file, but it was from around September, so I downloaded jetson-nano-sd-card-image-r32.2.zip, which appears to be the most recent version, and flashed that. Unfortunately the new one does not have the /etc/nv_tegra_release file either.
I tried replacing the Raspberry PI IMX219 with a Waveshare one that was bought specifically for the Nano. Things go a little better with the new one, I no longer get the kernel errors, and can capture frames. Unfortunately, the buffers I get back only contain zeros.
I tried the 12_camera_v4l2_cuda sample and there I also just get all-green images back (probably what the zero buffers look like after YUV->RGB conversion.)
The command suggested by Honey_Patouceul works, but the output .raw file only contains zeros. I’ve tried qv4l2 and I get a black window.
I can still run the camera via gstreamer and argus, but it is unclear if I would be able to achieve zero-copy reads to CUDA buffers with that approach.
Is it safe to conclude that v4l2 is just plain broken on the Jetson Nano?
then try to increase gain and/or exposure from qv4l2 (be sure to disable bypass as well) and try. If this doesn’t work, you may also try to disable argus deamon, reboot and try, but it’s only a suggestion, not sure it would really help.
The camera runs fine via argus, but with V4L2 there is no signal, just 0-filled frames. I have tried the suggestions to adjust gain & exposure and to reboot with argus disabled. Nothing helps.
That is shame, as Argus can get very unstable and leak a lot of memory at times.
Right now for instance, it has produced 3.2GiB worth of syslog containing mostly these errors:
Feb 20 12:26:16 jacob-desktop nvargus-daemon[26684]: (Argus) Error InvalidState: (propagating from src/api/ScfCaptureThread.cpp, function run(), line 109)
Feb 20 12:26:16 jacob-desktop nvargus-daemon[26684]: SCF: Error InvalidState: Session has suffered a critical failure (in src/api/Session.cpp, function capture(), line 667)
Feb 20 12:26:16 jacob-desktop nvargus-daemon[26684]: (Argus) Error InvalidState: (propagating from src/api/ScfCaptureThread.cpp, function run(), line 109)
In this wonderful Ubuntu world that seems to be the only supported way to use a Jetson, this in turn triggers systemd’s log mechanism to (apparently) go and read all of these log statement into memory, so that apart from being out of disk space, the rest of the system gets hosed too. I’d be hesitant to use any of this on a production system.
For information, please share your release version($ head -1 /etc/nv_tegra_release) and steps to reproduce the error. We will try to reproduce it by following the steps.
Hi DaneLLL, please see thread above for context wrt power supply and the (lack of) /etc/nv_tegra_release file, even after reflashing latest jetpack.
Wrt stability, my guess is that Argus runs fine if everything is done flawlessly in the client, but when experimenting or if unexpected events cause initialization to fail halfway through, Argus does very quickly get itself into a very bad state. I have screenshots of nvargus-daemon using 9.1GiB VIRT memory, and I have massive log files consisting of forever repeated log statements from Argus like this one:
Feb 20 17:53:04 jacob-desktop nvargus-daemon[10231]: SCF: Error InvalidState: Session has suffered a critical failure (in src/api/Session.cpp, function capture(), line 667)
that also indicate that Argus is not as stable as one would ideally hope to be able to take it into production.
Finally, there is the issue of black screens with v4l2. From kernel traces it looks like some magic TEGRA CIDs get configured by Argus that the v42l-examples do not show how to use. Perhaps NVIDIA would consider making Argus open source, that would really help.
Yes I believe that can work, because it is doing a clean shutdown after every iteration. Right now, after having a crash elsewhere in my code that causes my process to exit without calling argus shutdown, I can get this result:
$ gst-launch-1.0 nvarguscamerasrc num-buffers=300 sensor-id=0 ! 'video/x-raw(memory:NVMM),width=1920, height=1080, framerate=30/1, format=NV12' ! nvoverlaysink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:521 No cameras available
Got EOS from element "pipeline0".
Execution ended after 0:00:00.032277158
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
(Argus) Error EndOfFile: Unexpected error in reading socket (in src/rpc/socket/client/ClientSocketManager.cpp, function recvThreadCore(), line 266)
(Argus) Error EndOfFile: Receive worker failure, notifying 1 waiting threads (in src/rpc/socket/client/ClientSocketManager.cpp, function recvThreadCore(), line 340)
(Argus) Error InvalidState: Argus client is exiting with 1 outstanding client threads (in src/rpc/socket/client/ClientSocketManager.cpp, function recvThreadCore(), line 357)
(Argus) Error EndOfFile: Receiving thread terminated with error (in src/rpc/socket/client/ClientSocketManager.cpp, function recvThreadWrapper(), line 368)
(Argus) Error EndOfFile: Client thread received an error from socket (in src/rpc/socket/client/ClientSocketManager.cpp, function send(), line 145)
(Argus) Error EndOfFile: (propagating from src/rpc/socket/client/SocketClientDispatch.cpp, function dispatch(), line 87)
And the only way to repair argus is to completely reboot. Even restarting the systemd service is not enough to restore argus to a working state. I think your script needs to test various stages of unclean client shutdowns.
Yes that is what I tried, but restarting Argus is not always enough. I have to reboot.
Clean shutdowns are not always a possibility, so Argus should be able to detect a client disconnecting uncleanly and be able survive (“fault containment”). Same as would be the case if using a kernel device.