CRITICAL error message very confusing and appears incorrect

Andres Gonzalez andres.agoralabs at gmail.com
Thu Aug 25 23:03:32 UTC 2016


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



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/CRITICAL-error-message-very-confusing-and-appears-incorrect-tp4679245p4679248.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.


More information about the gstreamer-devel mailing list