CV2, GSTreamer, Python

I am using the nvidia nano to read the IP camera using the gstreamer with cv2 in python. Here is the code,

src = ('rtspsrc location={} latency={} ! queue ! ’
'rtph265depay ! h265parse ! omxh265dec ! ’
'nvvidconv ! ’
'video/x-raw,format=BGRx ! videoconvert ! video/x-raw,format=BGR ! ’
'queue ! appsink drop=1 ').format(‘rtsp://admin:1234@169.169.1.11/1/h265major/’, 200)

stream = cv2.VideoCapture(src, cv2.CAP_GSTREAMER)

It works good, but when the power off or the network connections is not stable, I lost the feed, but when the connection came back, the gstreamer is not reconnecting.

I get the error as Error in accessing camera

How to solve this, thanks

I moved this post to the jetson nano sub-category, the community here will be in a better position to help you.
Thanks

1 Like

Hi,
We have deprecated omxh265dec, so please use nvv4l2decoder.

We don’t have experience of hitting the error condition. Will you get stream=NULL in the condition? It yes, you may try to terminate the current pipeline and re-initialize it.

@DaneLLL, thanks for writing

I changed to nvv4l2decoder instead of omxh265dec

Then, when the power/network issue happened,

this is the information I got

(python3:29456): GStreamer-CRITICAL **:
Trying to dispose element queue7651, but it is in PLAYING instead of the NULL state.
You need to explicitly set elements to the NULL state before
dropping the final reference, to allow them to clean up.
This problem may also be caused by a refcounting bug in the
application or some element.

(python3:29456): GStreamer-CRITICAL **:
Trying to dispose element nvvconv3825, but it is in PLAYING instead of the NULL state.
You need to explicitly set elements to the NULL state before
dropping the final reference, to allow them to clean up.
This problem may also be caused by a refcounting bug in the
application or some element.

(python3:29456): GStreamer-CRITICAL **:
Trying to dispose element h265parse3825, but it is in PLAYING instead of the NULL state.
You need to explicitly set elements to the NULL state before
dropping the final reference, to allow them to clean up.
This problem may also be caused by a refcounting bug in the
application or some element.

(python3:29456): GStreamer-CRITICAL **:
Trying to dispose element rtph265depay3825, but it is in PLAYING instead of the NULL state.
You need to explicitly set elements to the NULL state before
dropping the final reference, to allow them to clean up.
This problem may also be caused by a refcounting bug in the
application or some element.

[ WARN:0] global /home/nvidia/host/build_opencv/nv_opencv/modules/videoio/src/cap_gstreamer.cpp (886) open OpenCV | GStreamer warning: unable to start pipeline

(python3:3412): GStreamer-CRITICAL **: 19:57:10.200: gst_caps_is_empty: assertion ‘GST_IS_CAPS (caps)’ failed

(python3:3412): GStreamer-CRITICAL **: 19:57:10.200: gst_caps_truncate: assertion ‘GST_IS_CAPS (caps)’ failed

(python3:3412): GStreamer-CRITICAL **: 19:57:10.200: gst_caps_fixate: assertion ‘GST_IS_CAPS (caps)’ failed

(python3:3412): GStreamer-CRITICAL **: 19:57:10.201: gst_caps_get_structure: assertion ‘GST_IS_CAPS (caps)’ failed

(python3:3412): GStreamer-CRITICAL **: 19:57:10.201: gst_structure_get_string: assertion ‘structure != NULL’ failed

(python3:3412): GStreamer-CRITICAL **: 19:57:10.201: gst_mini_object_unref: assertion ‘mini_object != NULL’ failed

After some time, the connection came back in few minutes, the feed is not working

Is there any possible solution for this, thanks

Hi,
Looks like the error is detected in gstreamer, hut not sure if it is passed to OpenCV. Does it return error code or null in this call:

stream = cv2.VideoCapture(src, cv2.CAP_GSTREAMER)

If it returns error in the call, you can terminate the pipeline and re-initialize a new one

@DaneLLL, I checked the code again,

stream = cv2.VideoCapture(src, cv2.CAP_GSTREAMER)

the program got hang/stuck in this line, nothing happens, just got hang in the cv2.VideoCapture function

Is there any solution, I searched many blogs, but didnt got any optimal solution,

thanks

You can detect if the connection is not working and in failing case try to recreate the source:

import cv2
import time

src='rtspsrc location=rtsp://127.0.0.1:8554/test latency=200 ! application/x-rtp,encoding-name=H265 ! rtph265depay ! h265parse ! nvv4l2decoder ! nvvidconv ! video/x-raw,format=BGRx ! videoconvert ! video/x-raw,format=BGR ! appsink drop=1'

while True:
	stream = cv2.VideoCapture(src, cv2.CAP_GSTREAMER)
	if not stream.isOpened():
		print 'Source not available'
		time.sleep(1)
	else:
		print 'source connected'
		while True:
			ret, frame = stream.read()
			if not ret:
				print 'Failed to read from stream'
				stream.release()
				break
			else:
				cv2.imshow('Test', frame)
				cv2.waitKey(1)

@Honey_Patouceul, I tried this before, I am connecting the IP camera to the jetson,

I closely observed, that when the camera is went offline, the stream.isOpened() stays True instead of False. I dont know why that happens, If you know the reason for this, please share

Then, I used ret to check the camera is online or not

thanks

Hi,
It looks not possible in OpenCV. We will need a bus to receive the error message:
Bus

But this programming seems not supported in OpenCV.

In OpenCV, if the error case is not handled in cv2.VideoCapture(), may not have other way to detect and handle the error.

The return code from VideoCapture.read() is enough. Just add some sleep when it failed if you want and it should be ok.

@DaneLLL, I connected the camera to jetson using the rtsp link, does the Bus will not be needed, Is there any possible way to solve this,

thanks

@DaneLLL , @Honey_Patouceul,

When the camera is went offline, I set in a loop to continuously connect and check the flag

I observed, that when the camera is went offline, I got this warning,

[ WARN:0] global /home/nvidia/host/build_opencv/nv_opencv/modules/videoio/src/cap_gstreamer.cpp (1757) handleMessage OpenCV | GStreamer warning: Embedded video playback halted; module rtspsrc6318 reported: Could not open resource for reading and writing.

this number rtspsrc6318, in the warning, starts from rtspsrc1 to rtspsrc4000 approx. when cv2.VideoCapture tries to connect every time

in between, rtspsrc1 to approx. rtspsrc4000, if the camera gets connected, I got the feed,

If it goes beyond 4000, and then after some time, the camera gets connected, the loop gets stuck in the cv2.VideoCapture function

Do you know any solution for this pattern,

thanks

Hi,
You can check the source code:
opencv/cap_gstreamer.cpp at 4.x · opencv/opencv · GitHub

See if it is reported to upper application layer. If it’s reported, should be able to add handling.

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