GStreamer-CRITICAL gst_mini_object_set_qdata: assertion 'object != NULL' failed

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

GStreamer-CRITICAL gst_mini_object_set_qdata: assertion ‘object != NULL’ failed
OR segmentation fault (core dump)

Hi, I am having issues cv2 and Gstreamer with a Raspberry PI camera (v2) on Jetson Nano
They started with ‘segmentation fault (core dump)’ for the simplist code but, in its defence, I think once its ‘core dumped’ the world is off its axis a bit and it is easy to retrigger.

This was with jetpack 4.5.1 and cv2 which was built (without qt5) using instructions at Install OpenCV 4.5 on Jetson Nano - Q-engineering
I tried it with cv2 4.5.2 and 4.5.1 and the results were the same.
As best I can tell the error occurs somewhere within

camera.release()

Often the program will work fine until that point.
In the test program it will print(“about to camera.release()”) but never gets to print("about to destroyAllWindows() ")

I then dropped back to jetpack 4.4.1 by doing a fresh flash.
I am not sure how kosher this pack is now as it immediatly went and updated, or half updated, itself and is giving ‘I am unhappy’ problem reports ever since
Again I built cv2 from the same source and instructions.

This time the test module gives an error “GStreamer-CRITICAL gst_mini_object_set_qdata: assertion ‘object != NULL’ failed”
at the same line - camera.release() but it recovers enough to continue to the end.

I also believe there is a correlation to the captured width/height vs the displayed width/height as seen in the spreadsheet.
For jetpack 4.5 the ‘fail’ means ‘segmentation fault (core dump)’ whereas for 4.4.1 it is “GStreamer-CRITICAL gst_mini_object_set_qdata: assertion ‘object != NULL’ failed”
some of these may be silly requests (like displaying more than you captured) but note it does do it, it just crashes on release.
BUT I dont think it should get so upset as to dump, eg capture at 1280x720 and display at 640x480 is not unreasonable.

The things passed with ‘nvarguscamerasrc’ are complete black magic to me. I have not been able to find an english version of what all that means so most settings are from whatever web site I started at.

Any help would be appreciated - If its just a silly parameter to ‘nvarguscamerasrc’ then its lucky I have time to spare :)
If it is a real bug then please advise where I could report it.
p.s. I have no interest in getting 4.4.1 working - I just fell back to see if that got rid of the error

video_matrix_combos.ods (14.7 KB)
test code to reproduce the problem =
cv2-seg_fault_test.py (1.5 KB)

camSet='nvarguscamerasrc !  video/x-raw(memory:NVMM), \
        width='+str(captureSize[0])+', \
        height='+str(captureSize[1])+', \
        format=NV12,  \
        framerate='+str(captureSize[2])+'/1 ! nvvidconv flip-method='+str(flip)+' ! video/x-raw,   \
        width='+str(displaySize[0])+', \
        height='+str(displaySize[1])+', \
        format=BGRx ! videoconvert ! video/x-raw, \
        format=BGR ! appsink'

Thanks jc

2

You may try adding drop=1 into appsink properties.

4

Honey, sorry to appear a complete idiot but just how would I achieve that ? I have not cracked the wierd syntax used for nvarguscamerasrc

5

Hi,
Please check if you can successfully run gst-launch-1.0 command:

$ gst-launch-1.0 nvarguscamerasrc ! nvoverlaysink

If it works, please try this sample:
OpenCV Video Capture with GStreamer doesn't work on ROS-melodic - #3 by DaneLLL

6

DaneLLL
Both these work fine. Like I said originally these nvarguscamerasrc settings come from some post - unspecified.
I lined up your working version with my not-working version to see the differences. It looks mine has a whole duplicate entry around video/x-raw could that be the issue?

-- yours
    cap = cv2.VideoCapture("nvarguscamerasrc ! video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080,format=(string)NV12, framerate=(fraction)30/1 ! nvvidconv                 ! video/x-raw,                                    format=(string)BGRx ! videoconvert                           ! appsink")
-- mine 
    cap = cv2.VideoCapture("nvarguscamerasrc ! video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080,format=(string)NV12, framerate=(fraction)30/1 ! nvvidconv   flip-method=0 ! video/x-raw, width=(int)1920, height=(int)1080, format=(string)BGRx ! videoconvert ! video/x-raw, format=BGR ! appsink")

If so could you please tell me why or point me to some site where I can correct the error of my ways :)
Thanks JC

7

Just add it after appsink:

... ! appsink drop=1

Without it, argus may have problems when you release or destroy the opencv capture. This may leave argus not available and it should restore in one minute. Maybe the difference with Dane’s pipeline is just that yours was tried when argus was not available. I don’t see any siginificative difference. flip-method=0 is useless as it is default option (no flip).

1 Like
8

Honey - that easy - who would have guessed :) Thanks

9

Honey, thanks again the ‘drop=1’ works !
If its doing a self-reset in the background no wonder I have been getting inconsisent and hard to reproduce test results.
I have another, easier to reproduce, ‘segmentation fault (core dump)’ issue but I will put another post up for that.
Thanks again JC

11

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