mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-12-25 01:30:38 +00:00
Code Issues 1 Projects Releases Wiki Activity
gstreamer/gst/rtpmanager/gstrtprtxsend.h

84 lines
2.6 KiB
C
Raw Normal View History

rtpmanager: add new rtprtxsend / rtprtxreceive elements The purpose of the sender RTX object is to keep a history of RTP packets up to a configurable limit (in time). It will listen for custom retransmission events from downstream. When it receives a request for retransmission, it will look up the requested seqnum in its list of stored packets. If the packet is available, it will create a RTX packet according to RFC 4588 and send this as an auxiliary stream. The receiver will listen to the custom retransmission events from the downstream jitterbuffer and will remember the SSRC1 of the stream and seqnum that was requested. When it sees a packet with one of the stored seqnum, it associates the SSRC2 of the stream with the SSRC1 of the master stream. From then on it knows that SSRC2 is the retransmission stream of SSRC1. This algorithm is stated in RFC 4588. For this algorithm to work, RFC4588 also states that no two pending retransmission requests can exist for the same seqnum and different SSRCs or else it would be impossible to associate the retransmission with the original requester SSRC. When the RTX receiver has associated the retransmission packets, it can depayload and forward them to the source pad of the element. RTX is SSRC-multiplexed Fixes https://bugzilla.gnome.org/show_bug.cgi?id=711084
2013-11-01 15:52:03 +00:00
/* RTP Retransmission sender element for GStreamer
*
* gstrtprtxsend.h:
*
* Copyright (C) 2013 Collabora Ltd.
* @author Julien Isorce <julien.isorce@collabora.co.uk>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Library General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Library General Public License for more details.
*
* You should have received a copy of the GNU Library General Public
* License along with this library; if not, write to the
* Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
* Boston, MA 02110-1301, USA.
*/
#ifndef __GST_RTP_RTX_SEND_H__
#define __GST_RTP_RTX_SEND_H__
#include <gst/gst.h>
#include <gst/rtp/gstrtpbuffer.h>
G_BEGIN_DECLS
#define GST_TYPE_RTP_RTX_SEND (gst_rtp_rtx_send_get_type())
#define GST_RTP_RTX_SEND(obj) (G_TYPE_CHECK_INSTANCE_CAST((obj),GST_TYPE_RTP_RTX_SEND, GstRtpRtxSend))
#define GST_RTP_RTX_SEND_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST((klass),GST_TYPE_RTP_RTX_SEND, GstRtpRtxSendClass))
#define GST_RTP_RTX_SEND_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), GST_TYPE_RTP_RTX_SEND, GstRtpRtxSendClass))
#define GST_IS_RTP_RTX_SEND(obj) (G_TYPE_CHECK_INSTANCE_TYPE((obj),GST_TYPE_RTP_RTX_SEND))
#define GST_IS_RTP_RTX_SEND_CLASS(obj) (G_TYPE_CHECK_CLASS_TYPE((klass),GST_TYPE_RTP_RTX_SEND))
typedef struct _GstRtpRtxSend GstRtpRtxSend;
typedef struct _GstRtpRtxSendClass GstRtpRtxSendClass;
struct _GstRtpRtxSend
{
GstElement element;
/* pad */
GstPad *sinkpad;
GstPad *srcpad;
/* rtp packets that will be pushed upon next buffer */
rtprtxsend: retransmit packets in the same order as the rtx requests
2013-11-04 16:38:24 +00:00
GQueue *pending;
rtpmanager: add new rtprtxsend / rtprtxreceive elements The purpose of the sender RTX object is to keep a history of RTP packets up to a configurable limit (in time). It will listen for custom retransmission events from downstream. When it receives a request for retransmission, it will look up the requested seqnum in its list of stored packets. If the packet is available, it will create a RTX packet according to RFC 4588 and send this as an auxiliary stream. The receiver will listen to the custom retransmission events from the downstream jitterbuffer and will remember the SSRC1 of the stream and seqnum that was requested. When it sees a packet with one of the stored seqnum, it associates the SSRC2 of the stream with the SSRC1 of the master stream. From then on it knows that SSRC2 is the retransmission stream of SSRC1. This algorithm is stated in RFC 4588. For this algorithm to work, RFC4588 also states that no two pending retransmission requests can exist for the same seqnum and different SSRCs or else it would be impossible to associate the retransmission with the original requester SSRC. When the RTX receiver has associated the retransmission packets, it can depayload and forward them to the source pad of the element. RTX is SSRC-multiplexed Fixes https://bugzilla.gnome.org/show_bug.cgi?id=711084
2013-11-01 15:52:03 +00:00
rtprtxsend: Allow SSRC-multiplexing and multiple payload types in the original stream Conflicts: tests/examples/rtp/server-rtpaux.c
2014-01-02 14:18:52 +00:00
/* ssrc -> SSRCRtxData */
GHashTable *ssrc_data;
/* rtx ssrc -> master ssrc */
GHashTable *rtx_ssrcs;
rtpmanager: add new rtprtxsend / rtprtxreceive elements The purpose of the sender RTX object is to keep a history of RTP packets up to a configurable limit (in time). It will listen for custom retransmission events from downstream. When it receives a request for retransmission, it will look up the requested seqnum in its list of stored packets. If the packet is available, it will create a RTX packet according to RFC 4588 and send this as an auxiliary stream. The receiver will listen to the custom retransmission events from the downstream jitterbuffer and will remember the SSRC1 of the stream and seqnum that was requested. When it sees a packet with one of the stored seqnum, it associates the SSRC2 of the stream with the SSRC1 of the master stream. From then on it knows that SSRC2 is the retransmission stream of SSRC1. This algorithm is stated in RFC 4588. For this algorithm to work, RFC4588 also states that no two pending retransmission requests can exist for the same seqnum and different SSRCs or else it would be impossible to associate the retransmission with the original requester SSRC. When the RTX receiver has associated the retransmission packets, it can depayload and forward them to the source pad of the element. RTX is SSRC-multiplexed Fixes https://bugzilla.gnome.org/show_bug.cgi?id=711084
2013-11-01 15:52:03 +00:00
rtprtxsend: Allow SSRC-multiplexing and multiple payload types in the original stream Conflicts: tests/examples/rtp/server-rtpaux.c
2014-01-02 14:18:52 +00:00
/* master ssrc -> rtx ssrc (property) */
GstStructure *external_ssrc_map;
rtprtxsend: Handle the max_size_time property This property allows you to specify the amount of buffers to keep in the retransmission queue expressed as time (ms) instead of buffer count (which is the max_size_buffers property).
2013-10-29 17:27:00 +00:00
rtprtxsend: Allow SSRC-multiplexing and multiple payload types in the original stream Conflicts: tests/examples/rtp/server-rtpaux.c
2014-01-02 14:18:52 +00:00
/* orig pt (uint) -> rtx pt (uint) */
GHashTable *rtx_pt_map;
/* orig pt (string) -> rtx pt (uint) */
rtprtxsend: change the rtx_pt_map directly in set_property() instead of delaying it for chain() The same lock is held, so there is no point in complicating it...
2014-01-14 11:13:49 +00:00
GstStructure *rtx_pt_map_structure;
rtprtxsend: Handle the max_size_time property This property allows you to specify the amount of buffers to keep in the retransmission queue expressed as time (ms) instead of buffer count (which is the max_size_buffers property).
2013-10-29 17:27:00 +00:00
/* buffering control properties */
rtpmanager: add new rtprtxsend / rtprtxreceive elements The purpose of the sender RTX object is to keep a history of RTP packets up to a configurable limit (in time). It will listen for custom retransmission events from downstream. When it receives a request for retransmission, it will look up the requested seqnum in its list of stored packets. If the packet is available, it will create a RTX packet according to RFC 4588 and send this as an auxiliary stream. The receiver will listen to the custom retransmission events from the downstream jitterbuffer and will remember the SSRC1 of the stream and seqnum that was requested. When it sees a packet with one of the stored seqnum, it associates the SSRC2 of the stream with the SSRC1 of the master stream. From then on it knows that SSRC2 is the retransmission stream of SSRC1. This algorithm is stated in RFC 4588. For this algorithm to work, RFC4588 also states that no two pending retransmission requests can exist for the same seqnum and different SSRCs or else it would be impossible to associate the retransmission with the original requester SSRC. When the RTX receiver has associated the retransmission packets, it can depayload and forward them to the source pad of the element. RTX is SSRC-multiplexed Fixes https://bugzilla.gnome.org/show_bug.cgi?id=711084
2013-11-01 15:52:03 +00:00
guint max_size_time;
guint max_size_packets;
/* statistics */
guint num_rtx_requests;
guint num_rtx_packets;
};
struct _GstRtpRtxSendClass
{
GstElementClass parent_class;
};
GType gst_rtp_rtx_send_get_type (void);
gboolean gst_rtp_rtx_send_plugin_init (GstPlugin * plugin);
G_END_DECLS
#endif /* __GST_RTP_RTX_SEND_H__ */
Reference in a new issue Copy permalink