Nvarguscamerasrc issues, related to OpenCV

Don’t worry about that, it’s not related.

Long answer is that the calibration file is for undistorting the image, but the mode I have started my program in doesn’t undistort, so disregard the “Failed to read camera parameters” and the “Can’t open file”, as these are both the same error.

Log order after any launch of my program is basically :
-Small dump of v4l2 detect data
-Warnings for missing calibration files
-Start the cameras, using gstreamer via VideoCapture.

During the log that I sent earlier, the program is launched 3 times : first time it works, but leave two threads of argus and 6 objects, that subsequent launches can’t get rid of.

For anyone willing to try, here is some code to reproduce the issue :

#include <opencv2/core.hpp>
#include <opencv2/highgui.hpp>
#include <iostream>

using namespace std;
using namespace cv;

int main(int argc, char** argv )
{
	cuda::setDevice(0);
	ocl::setUseOpenCL(true);

	VideoCapture* cap = new VideoCapture();
	cout << "Created video capture instance" << endl;
	cap->open("nvarguscamerasrc ! nvvidconv ! videoconvert ! appsink", CAP_GSTREAMER);
	cout << "Opened camera" << endl;
	int keypressed = 0;
	do
	{
		UMat image;
		cap->read(image);
		imshow("ArgusCamera", image);
		keypressed = waitKey(1);
	}
	while (keypressed != 27);
	return EXIT_SUCCESS;
}

Yes the camera isn’t getting released, but that doesn’t cause any issues for other cameras (USB and such). SIGTERM aren’t usually handled, so i believe that this use case is realistic, where users don’t clean up afterwards.

Did you verify by gst-launch-1.0 command line to open/close to confirm without problem?

Yes, it’s exactly the same as for the first messages in this conversation.

Are there any plugins registered in the gstreamer plugin blacklist?
show the blacklist:

gst-inspect-1.0 -b

Thanks for you reply.
Could you remind me the gst-launch-1.0 get the same failed?

Yes, I have the same results for the gst-launch.
Also the blacklist doesn’t have any plugins inside.

OK, that could be the sensor problem.
I would suggest consult to arducam for this issue.

You may also experiment with this test code. You’ll see it has a signal handler for termination, but it may be omitted if you add property drop=1 to appsink.

OK, that could be the sensor problem.
I would suggest consult to arducam for this issue.

It’s clearly a software issue though, as it works once, then complains that the objects haven’t been released, then doesn’t work. Other ways to access the camera work…
Is there a file somewhere that it’s writing to? Like a lock file? That would explain the persistence of the issue, and deleting it could partially fix the issue for me between reboots.

Please verify the sensor driver by v4l2-ctl like below command. Press CTRL + C to terminal it and run again much times to confirm it.

v4l2-ctl --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap

I get 21.2 fps, consistently, but no image is displayed.

v4l2-ctl won’t show the image.
Please run below command to set the frame rate to 30 and run above command more times.

v4l2-ctl -c frame_rate=30000000

I still get 21.2 fps. Is that important?

Actually the issue seems to be not because of opencv, but because of a small library I’m using to detect the cameras.
Source for it can be found here : jetsonMV/list-devices.hpp at main · robotronik/jetsonMV · GitHub
I’m going to investigate, but it seems to be the breaking thing.
The drop=1 argument is what pointed me in that direction.
EDIT : This is the actual source of this code GitHub - doleron/v4l2-list-devices: A single header file containing a single function to list camera devices on linux using V4L2 and ioctl

I’m marking it as solved : list-devices was breaking nvargus because the version that I had tried to communicate with non-camera devices while listing them, causing it to not work.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.