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