RTP losses management between gstrtpdepayload - gstrtppayload

Miguel París Díaz mparisdiaz at gmail.com
Fri Aug 1 06:23:56 PDT 2014


Hello,
I  and my team are developing a media-server based on GStreamer that
manages RTP streams (and RTCP).

Our pipeline (simplified) is as follow:

                                                            ==== RtpBin
========================
                                                            ||
____________         ______________   ||           ____________
__________
                  --- RTP_STREAM_A --->   ||  |                      |
     |                          |   ||           |                      |
        |                  |
CLIENT_A                                           ||  |  RtpSession  |
----> | RtpJitterBuffer  |   ||   --->   |   RtpDepay   |  --->  |   RtpPay
   |  -- RTP_STREAM_B --> ......... --> CLIENT_B
                  <-- RTCP_STREAM_A --   ||  |___________|
|_____________|   ||           |___________|          |_________|

||                                                                  ||

===================================

Following RFC 3550 (tools.ietf.org/html/rfc3550#section-7), in this case
our server acts as translator ("pseudo" because retransmissions are managed
by the server). and works fine in environments without losses, but it
sometimes does not when there are RTP packets losses and the video quality
is degraded.

Retransmissions are managed properly using RtpJitterBuffer, but also some
RTP packets can be considered lost. To solve this, PLI (
http://tools.ietf.org/html/rfc4585#section-6.3.1) request can be sent by
CLIENT_B, but it does not do this because RTP_STREAM_B does not have any
loss/gap.
I think that here is the problem, because as RFC 3550 says: "Losses in the
incoming packet stream may induce corresponding gaps in the outgoing
sequence numbers"

I have been studying GStreamer elements and thinking about some possible
solutions. I would like to have some opinions about them or a better one:

   - When a RTP packet is considered lost, RtpJitterBuffert sends out a
   GstRTPPacketLost event downstream which is managed by RtpDepay, and it
   sends a GST_EVENT_GAP downstream. Considering that this event is
   SERIALIZED, could we use it to induce a gap in RtpPay exactly in the
   correct sequence number?
   - What about using GST_BUFFER_FLAG_GAP in RtpJitterBuffer to mark lost
   packets?


Thanks in advance!!

-- 
Miguel París Díaz
------------------------------------------------------------------------
Computer/Software engineer.
Researcher in http://www.kurento.org
http://twitter.com/mparisdiaz
------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140801/ac3b809b/attachment.html>


More information about the gstreamer-devel mailing list