How to best obtain packet loss statistics from rtspsrc

Jesper Larsen knorr.jesper at
Mon Oct 26 00:57:30 PDT 2015


I have retrieved the statistics this way

1. Register a "new-manager" signal callback on rtspsrc to get the rtpbin
2. Register a "on-ssrc-active" signal callback on the rtpbin element
3. Emit the "get-internal-session" signal on the bin with session id from
callback 2)
4. Emit the "get-source-by-ssrc" signal on the session with the ssrc id
from callback 2) (not actually sure this signal is documented, but you can
find it in gst/rtpmanager/rtpsession.c)
5. Get the "stats" property from the rtpsource obtained in 4)

The API for all this has changed quite a bit, but this approach should work
on 1.4 and 1.6. Looks like there is new API that makes some shortcuts that
are marked for 1.8.


On Mon, Oct 26, 2015 at 5:48 AM, John Weber <rjohnweber at> wrote:

> Hi,
> I need to monitor packet loss statistics for a pipeline containing an
> rtspsrc.  I'm using it to receive a single H.264 video stream for decode
> and display on an IOS device.  I want to know packet loss for the RTP
> connection within the RTSP source.
> Based on some investigation into the Gstreamer source code and viewing a
> pipeline graph, the GstRtspSrc creates a GstRtpBin.  The GstRtpBin creates
> a GstRtpSession.  Within the session is an RtpSession object containing one
> or more RtpSource elements (in my case it should be only one).
> My original thought was to start search the pipeline for the GstRtpBin
> element using gst_bin_get_by_interface(), looking specifically for a
> GST_TYPE_RTP_BIN.  This doesn't seem to be easy or ideal because the header
> defining GST_TYPE_RTP_BIN (gstrtpbin.h within plugins-good) is specifically
> not exported for the development SDK.  This implies that the stuff I'm
> trying to get to is private data, not to be messed with at the application
> level.
> Ultimately, I want to be able to monitor packet loss and perhaps jitter
> statistics in real time, primarily for diagnostic reasons (like
> understanding the effect of various levels of packet loss on the decoder).
> Since what I'm trying to do now seems unnatural (or at least against the
> design intent), is there a better way to do this?
> Thanks,
> John
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gstreamer-devel mailing list