CRITICAL error message very confusing and appears incorrect

[Andres Gonzalez]

Hi,

I am using srtpenc with rtpbin and it appears to be working fine. However, when I unref the main pipeline I get the following errors:

GStreamer-CRITICAL **: gst_mini_object_unref: assertion 'mini_object->refcount > 0' failed
GStreamer-CRITICAL **:
Trying to dispose object "SrtpEncode-121", but it still has a parent "SrtpBin-121".
You need to let the parent manage the object instead of unreffing the object directly.

SrtpEncode-121 is the name of the srtpenc element and SrtpBin-121 is the name of the rtpbin.

The reason this appears confusing is that, my code did NOT add the srtpenc element to the rtpbin nor the main pipeline, so my code did not make the rtpbin the parent of the srtpenc element.  The srtpenc element was added internally by the rtpbin "request-rtp-encoder" callback and not by my code.  Also, I am NOT unreffing either the srtpenc element nor the rtpbin element (I am only unreffing the main pipeline) so my code is NOT "unreffing the object directly."  

Question: what is the correct way to use the srtpenc element so I can resolve this error?

Thanks,
-Andres

[Tim Müller]

On Thu, 2016-08-25 at 11:26 -0700, Andres Gonzalez wrote:

Hi Andres,

This is caused by a refcount bug "somewhere" - could be your code or
inside some GStreamer element. Something is unreffing something it
shouldn't, or forgot to ref something when it should.

If you can run this code through valgrind, it might show you the
previous code that unreffed that mini object. If you're lucky that's
the code where the bug is.

You're right that the message is confusing in this case, but we can't
tell who's fault it is, so the only thing we could do is remove the
extra text again, which is not helpful when it is actually the
application messing up the refcounting.

Cheers
 -Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Andres Gonzalez]

Thanks for your response Tim.

I agree with you--and please understand that I was not trying to be critical, just trying to describe the situation--error reporting is never perfect, at least my error code is never perfect.  :-)

But my biggest issue is that I am not sure if I am even using the srtpenc element correctly.  The usage of the srtpenc/srtpdec elements is NOT like the other GStreamer elements and there is no documentation nor example code that I can find for these elements.   srtpenc/srtpdec are not added to the bin like regular GStreamer element application code, and application code does not appear to have full responsibility for linking them like other GStreamer elements, only partial responsibility.

I say partial because I could not get the pipeline to link until I  created the Request pads: rtp_sink_$u and rtcp_sink_$u but did not link them.  I have tried both releasing those request pad before closing the main pipeline and NOT releasing those request pad before closing the main pipeline, but no difference in that these critical errors still occur.

Question: what is the correct way (high level proceedure) to use these elements?   If I can assure myself that I am using these elements correctly, then I can effectively debug my code. But if I am not sure I am even using them as the designer intended, then anything I do is just shooting in the dark.

For example, this pipeline does not link:
1) create rtpbin
2) register the signal callbacks "request-rtp-encoder" and "request-rtcp-encoder"
3) create srtpenc but do not add it to the bin
4) in the signal callbacks return a reference to srtpenc

this pipeline does indeed link and appears to work properly but causes critical errors when the main pipeline is unreffed:
1) create rtpbin
2) register the signal callbacks
3) create srtpenc but do not add it to the bin
4) create the Request pads "rtp-sink_$u" and "rtcp-sink-$u" but do not link them
5) in the signal callbacks return a reference to srtpenc

Releasing or not releasing the Request pads prior to unreffing the main pipeline has no effect in that the critical errors still occur.

The question in different words: Is the high level usage of the 2nd pipeline above the correct/complete way to use srtpenc?  If so, then my code is causing these critical errors and I will go back to debugging my code.

Thanks,
-Andres