How to best obtain packet loss statistics from rtspsrc

[Jesper Larsen]

Hello

I have retrieved the statistics this way

1. Register a "new-manager" signal callback on rtspsrc to get the rtpbin
element
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.

Jesper


On Mon, Oct 26, 2015 at 5:48 AM, John Weber <rjohnweber at gmail.com> 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 lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151026/59279a58/attachment.html>