mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-11-06 01:19:38 +00:00
Code Issues 1 Projects Releases Wiki Activity
gstreamer/gst/rtpmanager/gstrtprtxsend.c

952 lines
29 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.c:
*
* 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.
*/
/**
* SECTION:element-rtprtxsend
*
* See #GstRtpRtxReceive for examples
*
* The purpose of the sender RTX object is to keep a history of RTP packets up
* to a configurable limit (max-size-time or max-size-packets). It will listen
* for upstream custom retransmission events (GstRTPRetransmissionRequest) that
* comes from downstream (#GstRtpSession). When receiving a request 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. RTX is SSRC-multiplexed
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include <gst/gst.h>
#include <gst/rtp/gstrtpbuffer.h>
#include <string.h>
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
#include <stdlib.h>
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
#include "gstrtprtxsend.h"
GST_DEBUG_CATEGORY_STATIC (gst_rtp_rtx_send_debug);
#define GST_CAT_DEFAULT gst_rtp_rtx_send_debug
#define DEFAULT_RTX_PAYLOAD_TYPE 0
#define DEFAULT_MAX_SIZE_TIME 0
#define DEFAULT_MAX_SIZE_PACKETS 100
enum
{
PROP_0,
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
PROP_SSRC_MAP,
PROP_PAYLOAD_TYPE_MAP,
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
PROP_MAX_SIZE_TIME,
PROP_MAX_SIZE_PACKETS,
PROP_NUM_RTX_REQUESTS,
remove unused enum items PROP_LAST This were probably added to the enums due to cargo cult programming and are unused. Removing them.
2015-04-24 16:01:10 +00:00
PROP_NUM_RTX_PACKETS
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
};
static GstStaticPadTemplate src_factory = GST_STATIC_PAD_TEMPLATE ("src",
GST_PAD_SRC,
GST_PAD_ALWAYS,
GST_STATIC_CAPS ("application/x-rtp")
);
static GstStaticPadTemplate sink_factory = GST_STATIC_PAD_TEMPLATE ("sink",
GST_PAD_SINK,
GST_PAD_ALWAYS,
rtprtxsend: Require clock-rate in the caps and handle no ssrc in the caps properly
2014-04-17 15:58:58 +00:00
GST_STATIC_CAPS ("application/x-rtp, " "clock-rate = (int) [1, MAX]")
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: run a new GstTask on the src pad The reason behind this is to minimize the retransmission delay. Previously, when a NACK was received, rtprtxsend would put a retransmission packet in a queue and it would send it from chain(), i.e. only after a new buffer would arrive. This unfortunately was causing big delays, in the order of 60-100 ms, which can be critical for the receiver side. By having a separate GstTask for pushing buffers out of rtxsend, we can push buffers out right after receiving the event, without waiting for chain() to get called.
2014-01-15 08:46:14 +00:00
static gboolean gst_rtp_rtx_send_queue_check_full (GstDataQueue * queue,
guint visible, guint bytes, guint64 time, gpointer checkdata);
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
static gboolean gst_rtp_rtx_send_src_event (GstPad * pad, GstObject * parent,
GstEvent * event);
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
static gboolean gst_rtp_rtx_send_sink_event (GstPad * pad, GstObject * parent,
GstEvent * event);
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
static GstFlowReturn gst_rtp_rtx_send_chain (GstPad * pad, GstObject * parent,
GstBuffer * buffer);
rtprtxsend: Add support for buffer lists
2015-03-19 10:54:12 +00:00
static GstFlowReturn gst_rtp_rtx_send_chain_list (GstPad * pad,
GstObject * parent, GstBufferList * list);
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: run a new GstTask on the src pad The reason behind this is to minimize the retransmission delay. Previously, when a NACK was received, rtprtxsend would put a retransmission packet in a queue and it would send it from chain(), i.e. only after a new buffer would arrive. This unfortunately was causing big delays, in the order of 60-100 ms, which can be critical for the receiver side. By having a separate GstTask for pushing buffers out of rtxsend, we can push buffers out right after receiving the event, without waiting for chain() to get called.
2014-01-15 08:46:14 +00:00
static void gst_rtp_rtx_send_src_loop (GstRtpRtxSend * rtx);
static gboolean gst_rtp_rtx_send_activate_mode (GstPad * pad,
GstObject * parent, GstPadMode mode, gboolean active);
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
static GstStateChangeReturn gst_rtp_rtx_send_change_state (GstElement *
element, GstStateChange transition);
static void gst_rtp_rtx_send_set_property (GObject * object, guint prop_id,
const GValue * value, GParamSpec * pspec);
static void gst_rtp_rtx_send_get_property (GObject * object, guint prop_id,
GValue * value, GParamSpec * pspec);
static void gst_rtp_rtx_send_finalize (GObject * object);
G_DEFINE_TYPE (GstRtpRtxSend, gst_rtp_rtx_send, GST_TYPE_ELEMENT);
rtprtxsend: keep important buffer information in a private structure This is to avoid mapping a buffer every time we need to read a seqnum or a timestamp.
2013-11-02 13:21:08 +00:00
typedef struct
{
guint16 seqnum;
guint32 timestamp;
GstBuffer *buffer;
} BufferQueueItem;
static void
buffer_queue_item_free (BufferQueueItem * item)
{
gst_buffer_unref (item->buffer);
rtprtxsend: Use g_slice_* for allocating internal structures
2014-01-14 11:32:38 +00:00
g_slice_free (BufferQueueItem, item);
rtprtxsend: keep important buffer information in a private structure This is to avoid mapping a buffer every time we need to read a seqnum or a timestamp.
2013-11-02 13:21:08 +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
typedef struct
{
guint32 rtx_ssrc;
rtpsource/rtprtxsend: Also pass correct seqnum-offset and payload to the RTX rtpsource https://bugzilla.gnome.org/show_bug.cgi?id=747394
2015-04-16 13:31:25 +00:00
guint16 seqnum_base, next_seqnum;
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
gint clock_rate;
/* history of rtp packets */
GSequence *queue;
} SSRCRtxData;
static SSRCRtxData *
ssrc_rtx_data_new (guint32 rtx_ssrc)
{
rtprtxsend: Use g_slice_* for allocating internal structures
2014-01-14 11:32:38 +00:00
SSRCRtxData *data = g_slice_new0 (SSRCRtxData);
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
data->rtx_ssrc = rtx_ssrc;
rtpsource/rtprtxsend: Also pass correct seqnum-offset and payload to the RTX rtpsource https://bugzilla.gnome.org/show_bug.cgi?id=747394
2015-04-16 13:31:25 +00:00
data->next_seqnum = data->seqnum_base = g_random_int_range (0, G_MAXUINT16);
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
data->queue = g_sequence_new ((GDestroyNotify) buffer_queue_item_free);
return data;
}
static void
ssrc_rtx_data_free (SSRCRtxData * data)
{
g_sequence_free (data->queue);
rtprtxsend: Use g_slice_* for allocating internal structures
2014-01-14 11:32:38 +00:00
g_slice_free (SSRCRtxData, data);
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
}
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
static void
gst_rtp_rtx_send_class_init (GstRtpRtxSendClass * klass)
{
GObjectClass *gobject_class;
GstElementClass *gstelement_class;
gobject_class = (GObjectClass *) klass;
gstelement_class = (GstElementClass *) klass;
gobject_class->get_property = gst_rtp_rtx_send_get_property;
gobject_class->set_property = gst_rtp_rtx_send_set_property;
gobject_class->finalize = gst_rtp_rtx_send_finalize;
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
g_object_class_install_property (gobject_class, PROP_SSRC_MAP,
g_param_spec_boxed ("ssrc-map", "SSRC Map",
"Map of SSRCs to their retransmission SSRCs for SSRC-multiplexed mode"
" (default = random)", GST_TYPE_STRUCTURE,
G_PARAM_WRITABLE | G_PARAM_STATIC_STRINGS));
rtprtxsend: Add an rtx-ssrc property to allow external control of the ssrc This is useful when one needs to know the SSRC beforehands, so that it can be used for SRTP for example.
2013-11-25 14:00:45 +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
g_object_class_install_property (gobject_class, PROP_PAYLOAD_TYPE_MAP,
g_param_spec_boxed ("payload-type-map", "Payload Type Map",
"Map of original payload types to their retransmission payload types",
GST_TYPE_STRUCTURE, G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS));
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
g_object_class_install_property (gobject_class, PROP_MAX_SIZE_TIME,
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
g_param_spec_uint ("max-size-time", "Max Size Time",
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
"Amount of ms to queue (0 = unlimited)", 0, G_MAXUINT,
DEFAULT_MAX_SIZE_TIME, G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS));
g_object_class_install_property (gobject_class, PROP_MAX_SIZE_PACKETS,
g_param_spec_uint ("max-size-packets", "Max Size Packets",
rtprtxsend: use a realistic limit for the value of max-size-packets G_MAXINT16 is chosen because if the queue contains more than G_MAXINT16 packets, seqnum comparison will not work properly.
2013-11-05 07:33:51 +00:00
"Amount of packets to queue (0 = unlimited)", 0, G_MAXINT16,
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
DEFAULT_MAX_SIZE_PACKETS,
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS));
g_object_class_install_property (gobject_class, PROP_NUM_RTX_REQUESTS,
g_param_spec_uint ("num-rtx-requests", "Num RTX Requests",
"Number of retransmission events received", 0, G_MAXUINT,
0, G_PARAM_READABLE | G_PARAM_STATIC_STRINGS));
g_object_class_install_property (gobject_class, PROP_NUM_RTX_PACKETS,
g_param_spec_uint ("num-rtx-packets", "Num RTX Packets",
" Number of retransmission packets sent", 0, G_MAXUINT,
0, G_PARAM_READABLE | G_PARAM_STATIC_STRINGS));
good: use new gst_element_class_add_static_pad_template() https://bugzilla.gnome.org/show_bug.cgi?id=763076
2016-03-04 01:30:12 +00:00
gst_element_class_add_static_pad_template (gstelement_class, &src_factory);
gst_element_class_add_static_pad_template (gstelement_class, &sink_factory);
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
gst_element_class_set_static_metadata (gstelement_class,
"RTP Retransmission Sender", "Codec",
"Retransmit RTP packets when needed, according to RFC4588",
"Julien Isorce <julien.isorce@collabora.co.uk>");
gstelement_class->change_state =
GST_DEBUG_FUNCPTR (gst_rtp_rtx_send_change_state);
}
static void
rtprtxsend: remove unused parameter from the internal reset() method
2014-01-14 11:38:51 +00:00
gst_rtp_rtx_send_reset (GstRtpRtxSend * rtx)
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: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_LOCK (rtx);
rtprtxsend: run a new GstTask on the src pad The reason behind this is to minimize the retransmission delay. Previously, when a NACK was received, rtprtxsend would put a retransmission packet in a queue and it would send it from chain(), i.e. only after a new buffer would arrive. This unfortunately was causing big delays, in the order of 60-100 ms, which can be critical for the receiver side. By having a separate GstTask for pushing buffers out of rtxsend, we can push buffers out right after receiving the event, without waiting for chain() to get called.
2014-01-15 08:46:14 +00:00
gst_data_queue_flush (rtx->queue);
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
g_hash_table_remove_all (rtx->ssrc_data);
g_hash_table_remove_all (rtx->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
rtx->num_rtx_requests = 0;
rtx->num_rtx_packets = 0;
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_UNLOCK (rtx);
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
}
static void
gst_rtp_rtx_send_finalize (GObject * object)
{
GstRtpRtxSend *rtx = GST_RTP_RTX_SEND (object);
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
g_hash_table_unref (rtx->ssrc_data);
g_hash_table_unref (rtx->rtx_ssrcs);
if (rtx->external_ssrc_map)
gst_structure_free (rtx->external_ssrc_map);
g_hash_table_unref (rtx->rtx_pt_map);
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
if (rtx->rtx_pt_map_structure)
gst_structure_free (rtx->rtx_pt_map_structure);
rtprtxsend: run a new GstTask on the src pad The reason behind this is to minimize the retransmission delay. Previously, when a NACK was received, rtprtxsend would put a retransmission packet in a queue and it would send it from chain(), i.e. only after a new buffer would arrive. This unfortunately was causing big delays, in the order of 60-100 ms, which can be critical for the receiver side. By having a separate GstTask for pushing buffers out of rtxsend, we can push buffers out right after receiving the event, without waiting for chain() to get called.
2014-01-15 08:46:14 +00:00
g_object_unref (rtx->queue);
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
G_OBJECT_CLASS (gst_rtp_rtx_send_parent_class)->finalize (object);
}
static void
gst_rtp_rtx_send_init (GstRtpRtxSend * rtx)
{
GstElementClass *klass = GST_ELEMENT_GET_CLASS (rtx);
rtx->srcpad =
gst_pad_new_from_template (gst_element_class_get_pad_template (klass,
"src"), "src");
GST_PAD_SET_PROXY_CAPS (rtx->srcpad);
GST_PAD_SET_PROXY_ALLOCATION (rtx->srcpad);
gst_pad_set_event_function (rtx->srcpad,
GST_DEBUG_FUNCPTR (gst_rtp_rtx_send_src_event));
rtprtxsend: run a new GstTask on the src pad The reason behind this is to minimize the retransmission delay. Previously, when a NACK was received, rtprtxsend would put a retransmission packet in a queue and it would send it from chain(), i.e. only after a new buffer would arrive. This unfortunately was causing big delays, in the order of 60-100 ms, which can be critical for the receiver side. By having a separate GstTask for pushing buffers out of rtxsend, we can push buffers out right after receiving the event, without waiting for chain() to get called.
2014-01-15 08:46:14 +00:00
gst_pad_set_activatemode_function (rtx->srcpad,
GST_DEBUG_FUNCPTR (gst_rtp_rtx_send_activate_mode));
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
gst_element_add_pad (GST_ELEMENT (rtx), rtx->srcpad);
rtx->sinkpad =
gst_pad_new_from_template (gst_element_class_get_pad_template (klass,
"sink"), "sink");
GST_PAD_SET_PROXY_CAPS (rtx->sinkpad);
GST_PAD_SET_PROXY_ALLOCATION (rtx->sinkpad);
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
gst_pad_set_event_function (rtx->sinkpad,
GST_DEBUG_FUNCPTR (gst_rtp_rtx_send_sink_event));
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
gst_pad_set_chain_function (rtx->sinkpad,
GST_DEBUG_FUNCPTR (gst_rtp_rtx_send_chain));
rtprtxsend: Add support for buffer lists
2015-03-19 10:54:12 +00:00
gst_pad_set_chain_list_function (rtx->sinkpad,
GST_DEBUG_FUNCPTR (gst_rtp_rtx_send_chain_list));
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
gst_element_add_pad (GST_ELEMENT (rtx), rtx->sinkpad);
rtprtxsend: run a new GstTask on the src pad The reason behind this is to minimize the retransmission delay. Previously, when a NACK was received, rtprtxsend would put a retransmission packet in a queue and it would send it from chain(), i.e. only after a new buffer would arrive. This unfortunately was causing big delays, in the order of 60-100 ms, which can be critical for the receiver side. By having a separate GstTask for pushing buffers out of rtxsend, we can push buffers out right after receiving the event, without waiting for chain() to get called.
2014-01-15 08:46:14 +00:00
rtx->queue = gst_data_queue_new (gst_rtp_rtx_send_queue_check_full, NULL,
NULL, rtx);
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
rtx->ssrc_data = g_hash_table_new_full (g_direct_hash, g_direct_equal,
NULL, (GDestroyNotify) ssrc_rtx_data_free);
rtx->rtx_ssrcs = g_hash_table_new (g_direct_hash, g_direct_equal);
rtx->rtx_pt_map = g_hash_table_new (g_direct_hash, g_direct_equal);
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
rtx->max_size_time = DEFAULT_MAX_SIZE_TIME;
rtx->max_size_packets = DEFAULT_MAX_SIZE_PACKETS;
}
rtprtxsend: run a new GstTask on the src pad The reason behind this is to minimize the retransmission delay. Previously, when a NACK was received, rtprtxsend would put a retransmission packet in a queue and it would send it from chain(), i.e. only after a new buffer would arrive. This unfortunately was causing big delays, in the order of 60-100 ms, which can be critical for the receiver side. By having a separate GstTask for pushing buffers out of rtxsend, we can push buffers out right after receiving the event, without waiting for chain() to get called.
2014-01-15 08:46:14 +00:00
static void
gst_rtp_rtx_send_set_flushing (GstRtpRtxSend * rtx, gboolean flush)
{
GST_OBJECT_LOCK (rtx);
gst_data_queue_set_flushing (rtx->queue, flush);
gst_data_queue_flush (rtx->queue);
GST_OBJECT_UNLOCK (rtx);
}
static gboolean
gst_rtp_rtx_send_queue_check_full (GstDataQueue * queue,
guint visible, guint bytes, guint64 time, gpointer checkdata)
{
return FALSE;
}
static void
gst_rtp_rtx_data_queue_item_free (gpointer item)
{
GstDataQueueItem *data = item;
if (data->object)
gst_mini_object_unref (data->object);
g_slice_free (GstDataQueueItem, data);
}
static gboolean
gst_rtp_rtx_send_push_out (GstRtpRtxSend * rtx, gpointer object)
{
GstDataQueueItem *data;
gboolean success;
data = g_slice_new0 (GstDataQueueItem);
data->object = GST_MINI_OBJECT (object);
data->size = 1;
data->duration = 1;
data->visible = TRUE;
data->destroy = gst_rtp_rtx_data_queue_item_free;
success = gst_data_queue_push (rtx->queue, data);
if (!success)
data->destroy (data);
return success;
}
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
static guint32
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
gst_rtp_rtx_send_choose_ssrc (GstRtpRtxSend * rtx, guint32 choice,
gboolean consider_choice)
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
guint32 ssrc = consider_choice ? choice : g_random_int ();
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
/* make sure to be different than any other */
while (g_hash_table_contains (rtx->ssrc_data, GUINT_TO_POINTER (ssrc)) ||
g_hash_table_contains (rtx->rtx_ssrcs, GUINT_TO_POINTER (ssrc))) {
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
ssrc = g_random_int ();
}
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
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
return ssrc;
}
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
static SSRCRtxData *
gst_rtp_rtx_send_get_ssrc_data (GstRtpRtxSend * rtx, guint32 ssrc)
{
SSRCRtxData *data;
rtprtxsend: Fix unitialized variable compiler warning variable 'rtx_ssrc' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
2014-02-08 16:24:06 +00:00
guint32 rtx_ssrc = 0;
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
gboolean consider = FALSE;
if (G_UNLIKELY (!g_hash_table_contains (rtx->ssrc_data,
GUINT_TO_POINTER (ssrc)))) {
if (rtx->external_ssrc_map) {
gchar *ssrc_str;
ssrc_str = g_strdup_printf ("%" G_GUINT32_FORMAT, ssrc);
consider = gst_structure_get_uint (rtx->external_ssrc_map, ssrc_str,
&rtx_ssrc);
g_free (ssrc_str);
}
rtx_ssrc = gst_rtp_rtx_send_choose_ssrc (rtx, rtx_ssrc, consider);
data = ssrc_rtx_data_new (rtx_ssrc);
g_hash_table_insert (rtx->ssrc_data, GUINT_TO_POINTER (ssrc), data);
g_hash_table_insert (rtx->rtx_ssrcs, GUINT_TO_POINTER (rtx_ssrc),
GUINT_TO_POINTER (ssrc));
} else {
data = g_hash_table_lookup (rtx->ssrc_data, GUINT_TO_POINTER (ssrc));
}
return data;
}
rtprtxsend: fix data locking when creating rtx packets This patch moves the creation of rtx packets to be done early, in the src_event() function, when they are requested. The purpose is to run gst_rtp_rtx_buffer_new() with the object locked to protect internal data, because if it is done at the pushing stage, we would have to lock and unlock multiple times in a row while we are pushing the rtx buffers. Previously there was no locking at all, which was terribly wrong.
2014-01-14 12:01:41 +00:00
/* Copy fixed header and extension. Add OSN before to copy payload
* Copy memory to avoid to manually copy each rtp buffer field.
*/
static GstBuffer *
gst_rtp_rtx_buffer_new (GstRtpRtxSend * rtx, GstBuffer * buffer)
{
GstMemory *mem = NULL;
GstRTPBuffer rtp = GST_RTP_BUFFER_INIT;
GstRTPBuffer new_rtp = GST_RTP_BUFFER_INIT;
GstBuffer *new_buffer = gst_buffer_new ();
GstMapInfo map;
guint payload_len = 0;
SSRCRtxData *data;
guint32 ssrc;
guint16 seqnum;
guint8 fmtp;
gst_rtp_buffer_map (buffer, GST_MAP_READ, &rtp);
/* get needed data from GstRtpRtxSend */
ssrc = gst_rtp_buffer_get_ssrc (&rtp);
data = gst_rtp_rtx_send_get_ssrc_data (rtx, ssrc);
ssrc = data->rtx_ssrc;
seqnum = data->next_seqnum++;
fmtp = GPOINTER_TO_UINT (g_hash_table_lookup (rtx->rtx_pt_map,
GUINT_TO_POINTER (gst_rtp_buffer_get_payload_type (&rtp))));
rtprtx{send,receive}: improve the debug messages * use INFO/DEBUG/LOG/TRACE equaly and meaningfully; previously rtprtxsend:LOG and rtprtxreceive:LOG would generate a totally different amount of log traffic and sometimes it was impossible to see the information you wanted without useless spam being printed around * improve the wording, give a reasonable and self-explanatory amount of information * print SSRCs in hex * avoid G_FOO_FORMAT for readability (we are just printing integers)
2017-09-07 11:33:57 +00:00
GST_DEBUG_OBJECT (rtx, "creating rtx buffer, orig seqnum: %u, "
"rtx seqnum: %u, rtx ssrc: %X", gst_rtp_buffer_get_seq (&rtp),
rtprtxsend: fix data locking when creating rtx packets This patch moves the creation of rtx packets to be done early, in the src_event() function, when they are requested. The purpose is to run gst_rtp_rtx_buffer_new() with the object locked to protect internal data, because if it is done at the pushing stage, we would have to lock and unlock multiple times in a row while we are pushing the rtx buffers. Previously there was no locking at all, which was terribly wrong.
2014-01-14 12:01:41 +00:00
seqnum, ssrc);
/* gst_rtp_buffer_map does not map the payload so do it now */
gst_rtp_buffer_get_payload (&rtp);
/* copy fixed header */
mem = gst_memory_copy (rtp.map[0].memory, 0, rtp.size[0]);
gst_buffer_append_memory (new_buffer, mem);
/* copy extension if any */
if (rtp.size[1]) {
rtxsend: fix wrong memory layout assumption The code responsible for creating retransmitted buffers assumed the stored buffer had been created with rtp_buffer_new_allocate when copying the extension data, which isn't necessarily the case, for example when the rtp buffers come from a udpsrc. https://bugzilla.gnome.org/show_bug.cgi?id=794958
2018-04-03 23:48:44 +00:00
mem = gst_allocator_alloc (NULL, rtp.size[1], NULL);
gst_memory_map (mem, &map, GST_MAP_WRITE);
memcpy (map.data, rtp.data[1], rtp.size[1]);
gst_memory_unmap (mem, &map);
rtprtxsend: fix data locking when creating rtx packets This patch moves the creation of rtx packets to be done early, in the src_event() function, when they are requested. The purpose is to run gst_rtp_rtx_buffer_new() with the object locked to protect internal data, because if it is done at the pushing stage, we would have to lock and unlock multiple times in a row while we are pushing the rtx buffers. Previously there was no locking at all, which was terribly wrong.
2014-01-14 12:01:41 +00:00
gst_buffer_append_memory (new_buffer, mem);
}
/* copy payload and add OSN just before */
payload_len = 2 + rtp.size[2];
mem = gst_allocator_alloc (NULL, payload_len, NULL);
gst_memory_map (mem, &map, GST_MAP_WRITE);
GST_WRITE_UINT16_BE (map.data, gst_rtp_buffer_get_seq (&rtp));
if (rtp.size[2])
memcpy (map.data + 2, rtp.data[2], rtp.size[2]);
gst_memory_unmap (mem, &map);
gst_buffer_append_memory (new_buffer, mem);
/* everything needed is copied */
gst_rtp_buffer_unmap (&rtp);
/* set ssrc, seqnum and fmtp */
gst_rtp_buffer_map (new_buffer, GST_MAP_WRITE, &new_rtp);
gst_rtp_buffer_set_ssrc (&new_rtp, ssrc);
gst_rtp_buffer_set_seq (&new_rtp, seqnum);
gst_rtp_buffer_set_payload_type (&new_rtp, fmtp);
/* RFC 4588: let other elements do the padding, as normal */
gst_rtp_buffer_set_padding (&new_rtp, FALSE);
gst_rtp_buffer_unmap (&new_rtp);
rtprtxsend: Copy over timestamps from the orignal buffers to the RTX buffers https://bugzilla.gnome.org/show_bug.cgi?id=747394
2015-04-14 11:56:38 +00:00
/* Copy over timestamps */
gst_buffer_copy_into (new_buffer, buffer, GST_BUFFER_COPY_TIMESTAMPS, 0, -1);
rtprtxsend: fix data locking when creating rtx packets This patch moves the creation of rtx packets to be done early, in the src_event() function, when they are requested. The purpose is to run gst_rtp_rtx_buffer_new() with the object locked to protect internal data, because if it is done at the pushing stage, we would have to lock and unlock multiple times in a row while we are pushing the rtx buffers. Previously there was no locking at all, which was terribly wrong.
2014-01-14 12:01:41 +00:00
return new_buffer;
}
rtprtxsend: use a GSequence to implement the buffer queue This has the advantage that searching the queue to find the buffer with the requested seqnum is done with binary search.
2013-11-04 18:05:03 +00:00
static gint
buffer_queue_items_cmp (BufferQueueItem * a, BufferQueueItem * b,
gpointer user_data)
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: use a GSequence to implement the buffer queue This has the advantage that searching the queue to find the buffer with the requested seqnum is done with binary search.
2013-11-04 18:05:03 +00:00
/* gst_rtp_buffer_compare_seqnum returns the opposite of what we want,
* it returns negative when seqnum1 > seqnum2 and we want negative
* when b > a, i.e. a is smaller, so it comes first in the sequence */
return gst_rtp_buffer_compare_seqnum (b->seqnum, a->seqnum);
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
}
static gboolean
gst_rtp_rtx_send_src_event (GstPad * pad, GstObject * parent, GstEvent * event)
{
GstRtpRtxSend *rtx = GST_RTP_RTX_SEND (parent);
gboolean res;
switch (GST_EVENT_TYPE (event)) {
case GST_EVENT_CUSTOM_UPSTREAM:
{
const GstStructure *s = gst_event_get_structure (event);
/* This event usually comes from the downstream gstrtpsession */
if (gst_structure_has_name (s, "GstRTPRetransmissionRequest")) {
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
guint seqnum = 0;
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 ssrc = 0;
rtprtxsend: run a new GstTask on the src pad The reason behind this is to minimize the retransmission delay. Previously, when a NACK was received, rtprtxsend would put a retransmission packet in a queue and it would send it from chain(), i.e. only after a new buffer would arrive. This unfortunately was causing big delays, in the order of 60-100 ms, which can be critical for the receiver side. By having a separate GstTask for pushing buffers out of rtxsend, we can push buffers out right after receiving the event, without waiting for chain() to get called.
2014-01-15 08:46:14 +00:00
GstBuffer *rtx_buf = NULL;
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
rtprtx*: Fix typos
2015-04-14 17:08:24 +00:00
/* retrieve seqnum of the packet that need to be retransmitted */
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
if (!gst_structure_get_uint (s, "seqnum", &seqnum))
seqnum = -1;
rtprtx*: Fix typos
2015-04-14 17:08:24 +00:00
/* retrieve ssrc of the packet that need to be retransmitted */
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
if (!gst_structure_get_uint (s, "ssrc", &ssrc))
ssrc = -1;
rtprtx{send,receive}: improve the debug messages * use INFO/DEBUG/LOG/TRACE equaly and meaningfully; previously rtprtxsend:LOG and rtprtxreceive:LOG would generate a totally different amount of log traffic and sometimes it was impossible to see the information you wanted without useless spam being printed around * improve the wording, give a reasonable and self-explanatory amount of information * print SSRCs in hex * avoid G_FOO_FORMAT for readability (we are just printing integers)
2017-09-07 11:33:57 +00:00
GST_DEBUG_OBJECT (rtx, "got rtx request for seqnum: %u, ssrc: %X",
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
seqnum, ssrc);
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_LOCK (rtx);
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
/* check if request is for us */
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
if (g_hash_table_contains (rtx->ssrc_data, GUINT_TO_POINTER (ssrc))) {
SSRCRtxData *data;
rtprtxsend: use a GSequence to implement the buffer queue This has the advantage that searching the queue to find the buffer with the requested seqnum is done with binary search.
2013-11-04 18:05:03 +00:00
GSequenceIter *iter;
BufferQueueItem search_item;
/* update statistics */
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
++rtx->num_rtx_requests;
rtprtxsend: use a GSequence to implement the buffer queue This has the advantage that searching the queue to find the buffer with the requested seqnum is done with binary search.
2013-11-04 18:05: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
data = gst_rtp_rtx_send_get_ssrc_data (rtx, ssrc);
rtprtxsend: use a GSequence to implement the buffer queue This has the advantage that searching the queue to find the buffer with the requested seqnum is done with binary search.
2013-11-04 18:05:03 +00:00
search_item.seqnum = seqnum;
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
iter = g_sequence_lookup (data->queue, &search_item,
rtprtxsend: use a GSequence to implement the buffer queue This has the advantage that searching the queue to find the buffer with the requested seqnum is done with binary search.
2013-11-04 18:05:03 +00:00
(GCompareDataFunc) buffer_queue_items_cmp, NULL);
if (iter) {
BufferQueueItem *item = g_sequence_get (iter);
rtprtx{send,receive}: improve the debug messages * use INFO/DEBUG/LOG/TRACE equaly and meaningfully; previously rtprtxsend:LOG and rtprtxreceive:LOG would generate a totally different amount of log traffic and sometimes it was impossible to see the information you wanted without useless spam being printed around * improve the wording, give a reasonable and self-explanatory amount of information * print SSRCs in hex * avoid G_FOO_FORMAT for readability (we are just printing integers)
2017-09-07 11:33:57 +00:00
GST_LOG_OBJECT (rtx, "found %u", item->seqnum);
rtprtxsend: run a new GstTask on the src pad The reason behind this is to minimize the retransmission delay. Previously, when a NACK was received, rtprtxsend would put a retransmission packet in a queue and it would send it from chain(), i.e. only after a new buffer would arrive. This unfortunately was causing big delays, in the order of 60-100 ms, which can be critical for the receiver side. By having a separate GstTask for pushing buffers out of rtxsend, we can push buffers out right after receiving the event, without waiting for chain() to get called.
2014-01-15 08:46:14 +00:00
rtx_buf = gst_rtp_rtx_buffer_new (rtx, item->buffer);
rtprtxsend: use a GSequence to implement the buffer queue This has the advantage that searching the queue to find the buffer with the requested seqnum is done with binary search.
2013-11-04 18:05:03 +00:00
}
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: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_UNLOCK (rtx);
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: run a new GstTask on the src pad The reason behind this is to minimize the retransmission delay. Previously, when a NACK was received, rtprtxsend would put a retransmission packet in a queue and it would send it from chain(), i.e. only after a new buffer would arrive. This unfortunately was causing big delays, in the order of 60-100 ms, which can be critical for the receiver side. By having a separate GstTask for pushing buffers out of rtxsend, we can push buffers out right after receiving the event, without waiting for chain() to get called.
2014-01-15 08:46:14 +00:00
if (rtx_buf)
gst_rtp_rtx_send_push_out (rtx, rtx_buf);
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
gst_event_unref (event);
res = TRUE;
/* This event usually comes from the downstream gstrtpsession */
} else if (gst_structure_has_name (s, "GstRTPCollision")) {
guint ssrc = 0;
if (!gst_structure_get_uint (s, "ssrc", &ssrc))
ssrc = -1;
rtprtx{send,receive}: improve the debug messages * use INFO/DEBUG/LOG/TRACE equaly and meaningfully; previously rtprtxsend:LOG and rtprtxreceive:LOG would generate a totally different amount of log traffic and sometimes it was impossible to see the information you wanted without useless spam being printed around * improve the wording, give a reasonable and self-explanatory amount of information * print SSRCs in hex * avoid G_FOO_FORMAT for readability (we are just printing integers)
2017-09-07 11:33:57 +00:00
GST_DEBUG_OBJECT (rtx, "got ssrc collision, ssrc: %X", ssrc);
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: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_LOCK (rtx);
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
/* choose another ssrc for our retransmited stream */
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
if (g_hash_table_contains (rtx->rtx_ssrcs, GUINT_TO_POINTER (ssrc))) {
guint master_ssrc;
SSRCRtxData *data;
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 = GPOINTER_TO_UINT (g_hash_table_lookup (rtx->rtx_ssrcs,
GUINT_TO_POINTER (ssrc)));
data = gst_rtp_rtx_send_get_ssrc_data (rtx, master_ssrc);
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
/* change rtx_ssrc and update the reverse map */
data->rtx_ssrc = gst_rtp_rtx_send_choose_ssrc (rtx, 0, FALSE);
g_hash_table_remove (rtx->rtx_ssrcs, GUINT_TO_POINTER (ssrc));
g_hash_table_insert (rtx->rtx_ssrcs,
GUINT_TO_POINTER (data->rtx_ssrc),
GUINT_TO_POINTER (master_ssrc));
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: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_UNLOCK (rtx);
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
/* no need to forward to payloader because we make sure to have
* a different ssrc
*/
gst_event_unref (event);
res = TRUE;
} else {
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
/* if master ssrc has collided, remove it from our data, as it
* is not going to be used any longer */
if (g_hash_table_contains (rtx->ssrc_data, GUINT_TO_POINTER (ssrc))) {
SSRCRtxData *data;
data = gst_rtp_rtx_send_get_ssrc_data (rtx, ssrc);
g_hash_table_remove (rtx->rtx_ssrcs,
GUINT_TO_POINTER (data->rtx_ssrc));
g_hash_table_remove (rtx->ssrc_data, GUINT_TO_POINTER (ssrc));
}
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_UNLOCK (rtx);
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
/* forward event to payloader in case collided ssrc is
* master stream */
res = gst_pad_event_default (pad, parent, event);
}
} else {
res = gst_pad_event_default (pad, parent, event);
}
break;
}
default:
res = gst_pad_event_default (pad, parent, event);
break;
}
return res;
}
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
static gboolean
gst_rtp_rtx_send_sink_event (GstPad * pad, GstObject * parent, GstEvent * event)
{
GstRtpRtxSend *rtx = GST_RTP_RTX_SEND (parent);
switch (GST_EVENT_TYPE (event)) {
rtprtxsend: run a new GstTask on the src pad The reason behind this is to minimize the retransmission delay. Previously, when a NACK was received, rtprtxsend would put a retransmission packet in a queue and it would send it from chain(), i.e. only after a new buffer would arrive. This unfortunately was causing big delays, in the order of 60-100 ms, which can be critical for the receiver side. By having a separate GstTask for pushing buffers out of rtxsend, we can push buffers out right after receiving the event, without waiting for chain() to get called.
2014-01-15 08:46:14 +00:00
case GST_EVENT_FLUSH_START:
gst_pad_push_event (rtx->srcpad, event);
gst_rtp_rtx_send_set_flushing (rtx, TRUE);
gst_pad_pause_task (rtx->srcpad);
return TRUE;
case GST_EVENT_FLUSH_STOP:
gst_pad_push_event (rtx->srcpad, event);
gst_rtp_rtx_send_set_flushing (rtx, FALSE);
gst_pad_start_task (rtx->srcpad,
(GstTaskFunction) gst_rtp_rtx_send_src_loop, rtx, NULL);
return TRUE;
rtprtxsend: ensure that no rtx buffers are sent after EOS To do that, enqueue the EOS event to be sent from the srcpad task thread and flush the queue right afterwards, so that no more rtx buffers can be sent, even if there are more requests coming in. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=722370
2014-01-21 12:42:38 +00:00
case GST_EVENT_EOS:
GST_INFO_OBJECT (rtx, "Got EOS - enqueueing it");
gst_rtp_rtx_send_push_out (rtx, event);
return TRUE;
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
case GST_EVENT_CAPS:
{
GstCaps *caps;
GstStructure *s;
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
guint ssrc;
rtpsource/rtprtxsend: Also pass correct seqnum-offset and payload to the RTX rtpsource https://bugzilla.gnome.org/show_bug.cgi?id=747394
2015-04-16 13:31:25 +00:00
gint payload;
gpointer rtx_payload;
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
SSRCRtxData *data;
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
gst_event_parse_caps (event, &caps);
s = gst_caps_get_structure (caps, 0);
rtprtxsend: Require clock-rate in the caps and handle no ssrc in the caps properly
2014-04-17 15:58:58 +00:00
if (!gst_structure_get_uint (s, "ssrc", &ssrc))
ssrc = -1;
rtpsource/rtprtxsend: Also pass correct seqnum-offset and payload to the RTX rtpsource https://bugzilla.gnome.org/show_bug.cgi?id=747394
2015-04-16 13:31:25 +00:00
if (!gst_structure_get_int (s, "payload", &payload))
payload = -1;
if (payload == -1)
GST_WARNING_OBJECT (rtx, "No payload in caps");
rtprtxsend: lock access to internal data in sink_event() function
2014-01-14 11:50:23 +00:00
GST_OBJECT_LOCK (rtx);
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
data = gst_rtp_rtx_send_get_ssrc_data (rtx, ssrc);
rtpsource/rtprtxsend: Also pass correct seqnum-offset and payload to the RTX rtpsource https://bugzilla.gnome.org/show_bug.cgi?id=747394
2015-04-16 13:31:25 +00:00
if (!g_hash_table_lookup_extended (rtx->rtx_pt_map,
GUINT_TO_POINTER (payload), NULL, &rtx_payload))
rtx_payload = GINT_TO_POINTER (-1);
if (GPOINTER_TO_INT (rtx_payload) == -1 && payload != -1)
GST_WARNING_OBJECT (rtx, "Payload %d not in rtx-pt-map", payload);
GST_DEBUG_OBJECT (rtx,
rtprtx{send,receive}: improve the debug messages * use INFO/DEBUG/LOG/TRACE equaly and meaningfully; previously rtprtxsend:LOG and rtprtxreceive:LOG would generate a totally different amount of log traffic and sometimes it was impossible to see the information you wanted without useless spam being printed around * improve the wording, give a reasonable and self-explanatory amount of information * print SSRCs in hex * avoid G_FOO_FORMAT for readability (we are just printing integers)
2017-09-07 11:33:57 +00:00
"got caps for payload: %d->%d, ssrc: %u->%u : %" GST_PTR_FORMAT,
payload, GPOINTER_TO_INT (rtx_payload), ssrc, data->rtx_ssrc, caps);
rtpsource/rtprtxsend: Also pass correct seqnum-offset and payload to the RTX rtpsource https://bugzilla.gnome.org/show_bug.cgi?id=747394
2015-04-16 13:31:25 +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
gst_structure_get_int (s, "clock-rate", &data->clock_rate);
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
rtpsession: Track RTX ssrc caps This is needed so that we can generate SR for RTX stream correctly (the clock rate is required). https://bugzilla.gnome.org/show_bug.cgi?id=747394
2015-04-06 07:26:50 +00:00
/* The session might need to know the RTX ssrc */
caps = gst_caps_copy (caps);
rtpsource/rtprtxsend: Also pass correct seqnum-offset and payload to the RTX rtpsource https://bugzilla.gnome.org/show_bug.cgi?id=747394
2015-04-16 13:31:25 +00:00
gst_caps_set_simple (caps, "rtx-ssrc", G_TYPE_UINT, data->rtx_ssrc,
"rtx-seqnum-offset", G_TYPE_UINT, data->seqnum_base, NULL);
if (GPOINTER_TO_INT (rtx_payload) != -1)
gst_caps_set_simple (caps, "rtx-payload", G_TYPE_INT,
GPOINTER_TO_INT (rtx_payload), NULL);
rtpsession: Track RTX ssrc caps This is needed so that we can generate SR for RTX stream correctly (the clock rate is required). https://bugzilla.gnome.org/show_bug.cgi?id=747394
2015-04-06 07:26:50 +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
GST_DEBUG_OBJECT (rtx, "got clock-rate from caps: %d for ssrc: %u",
data->clock_rate, ssrc);
rtprtxsend: lock access to internal data in sink_event() function
2014-01-14 11:50:23 +00:00
GST_OBJECT_UNLOCK (rtx);
rtpsession: Track RTX ssrc caps This is needed so that we can generate SR for RTX stream correctly (the clock rate is required). https://bugzilla.gnome.org/show_bug.cgi?id=747394
2015-04-06 07:26:50 +00:00
gst_event_unref (event);
event = gst_event_new_caps (caps);
gst_caps_unref (caps);
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
break;
}
default:
break;
}
return gst_pad_event_default (pad, parent, event);
}
/* like rtp_jitter_buffer_get_ts_diff() */
static guint32
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
gst_rtp_rtx_send_get_ts_diff (SSRCRtxData * data)
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
{
guint64 high_ts, low_ts;
BufferQueueItem *high_buf, *low_buf;
guint32 result;
rtprtxsend: use a GSequence to implement the buffer queue This has the advantage that searching the queue to find the buffer with the requested seqnum is done with binary search.
2013-11-04 18:05:03 +00:00
high_buf =
g_sequence_get (g_sequence_iter_prev (g_sequence_get_end_iter
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
(data->queue)));
low_buf = g_sequence_get (g_sequence_get_begin_iter (data->queue));
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
if (!high_buf || !low_buf || high_buf == low_buf)
return 0;
high_ts = high_buf->timestamp;
low_ts = low_buf->timestamp;
/* it needs to work if ts wraps */
if (high_ts >= low_ts) {
result = (guint32) (high_ts - low_ts);
} else {
result = (guint32) (high_ts + G_MAXUINT32 + 1 - low_ts);
}
/* return value in ms instead of clock ticks */
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
return (guint32) gst_util_uint64_scale_int (result, 1000, data->clock_rate);
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: Add support for buffer lists
2015-03-19 10:54:12 +00:00
/* Must be called with lock */
static void
process_buffer (GstRtpRtxSend * rtx, GstBuffer * buffer)
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
{
GstRTPBuffer rtp = GST_RTP_BUFFER_INIT;
rtprtxsend: keep important buffer information in a private structure This is to avoid mapping a buffer every time we need to read a seqnum or a timestamp.
2013-11-02 13:21:08 +00:00
BufferQueueItem *item;
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
SSRCRtxData *data;
rtprtxsend: keep important buffer information in a private structure This is to avoid mapping a buffer every time we need to read a seqnum or a timestamp.
2013-11-02 13:21:08 +00:00
guint16 seqnum;
rtprtxsend: do not keep history of packets with an unknown payload type This allows to disable retransmission per payload type by not putting a certain payload type in the map.
2013-11-29 18:58:26 +00:00
guint8 payload_type;
rtprtxsend: keep important buffer information in a private structure This is to avoid mapping a buffer every time we need to read a seqnum or a timestamp.
2013-11-02 13:21:08 +00:00
guint32 ssrc, rtptime;
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: keep important buffer information in a private structure This is to avoid mapping a buffer every time we need to read a seqnum or a timestamp.
2013-11-02 13:21:08 +00:00
/* read the information we want from the buffer */
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
gst_rtp_buffer_map (buffer, GST_MAP_READ, &rtp);
seqnum = gst_rtp_buffer_get_seq (&rtp);
rtprtxsend: do not keep history of packets with an unknown payload type This allows to disable retransmission per payload type by not putting a certain payload type in the map.
2013-11-29 18:58:26 +00:00
payload_type = gst_rtp_buffer_get_payload_type (&rtp);
rtprtxsend: keep important buffer information in a private structure This is to avoid mapping a buffer every time we need to read a seqnum or a timestamp.
2013-11-02 13:21:08 +00:00
ssrc = gst_rtp_buffer_get_ssrc (&rtp);
rtptime = gst_rtp_buffer_get_timestamp (&rtp);
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
gst_rtp_buffer_unmap (&rtp);
rtprtx{send,receive}: improve the debug messages * use INFO/DEBUG/LOG/TRACE equaly and meaningfully; previously rtprtxsend:LOG and rtprtxreceive:LOG would generate a totally different amount of log traffic and sometimes it was impossible to see the information you wanted without useless spam being printed around * improve the wording, give a reasonable and self-explanatory amount of information * print SSRCs in hex * avoid G_FOO_FORMAT for readability (we are just printing integers)
2017-09-07 11:33:57 +00:00
GST_TRACE_OBJECT (rtx, "Processing buffer seqnum: %u, ssrc: %X", seqnum,
ssrc);
rtprtxsend: keep important buffer information in a private structure This is to avoid mapping a buffer every time we need to read a seqnum or a timestamp.
2013-11-02 13:21:08 +00:00
rtprtxsend: do not keep history of packets with an unknown payload type This allows to disable retransmission per payload type by not putting a certain payload type in the map.
2013-11-29 18:58:26 +00:00
/* do not store the buffer if it's payload type is unknown */
if (g_hash_table_contains (rtx->rtx_pt_map, GUINT_TO_POINTER (payload_type))) {
data = gst_rtp_rtx_send_get_ssrc_data (rtx, ssrc);
/* add current rtp buffer to queue history */
rtprtxsend: Use g_slice_* for allocating internal structures
2014-01-14 11:32:38 +00:00
item = g_slice_new0 (BufferQueueItem);
rtprtxsend: do not keep history of packets with an unknown payload type This allows to disable retransmission per payload type by not putting a certain payload type in the map.
2013-11-29 18:58:26 +00:00
item->seqnum = seqnum;
item->timestamp = rtptime;
item->buffer = gst_buffer_ref (buffer);
g_sequence_append (data->queue, item);
/* remove oldest packets from history if they are too many */
if (rtx->max_size_packets) {
while (g_sequence_get_length (data->queue) > rtx->max_size_packets)
g_sequence_remove (g_sequence_get_begin_iter (data->queue));
}
if (rtx->max_size_time) {
while (gst_rtp_rtx_send_get_ts_diff (data) > rtx->max_size_time)
g_sequence_remove (g_sequence_get_begin_iter (data->queue));
}
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: Add support for buffer lists
2015-03-19 10:54:12 +00:00
}
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: Add support for buffer lists
2015-03-19 10:54:12 +00:00
static GstFlowReturn
gst_rtp_rtx_send_chain (GstPad * pad, GstObject * parent, GstBuffer * buffer)
{
GstRtpRtxSend *rtx = GST_RTP_RTX_SEND (parent);
GstFlowReturn ret;
GST_OBJECT_LOCK (rtx);
process_buffer (rtx, buffer);
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_UNLOCK (rtx);
rtprtxsend: Add support for buffer lists
2015-03-19 10:54:12 +00:00
ret = gst_pad_push (rtx->srcpad, buffer);
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: Add support for buffer lists
2015-03-19 10:54:12 +00:00
return ret;
}
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: Add support for buffer lists
2015-03-19 10:54:12 +00:00
static gboolean
process_buffer_from_list (GstBuffer ** buffer, guint idx, gpointer user_data)
{
process_buffer (user_data, *buffer);
return TRUE;
}
static GstFlowReturn
gst_rtp_rtx_send_chain_list (GstPad * pad, GstObject * parent,
GstBufferList * list)
{
GstRtpRtxSend *rtx = GST_RTP_RTX_SEND (parent);
GstFlowReturn ret;
GST_OBJECT_LOCK (rtx);
gst_buffer_list_foreach (list, process_buffer_from_list, rtx);
GST_OBJECT_UNLOCK (rtx);
ret = gst_pad_push_list (rtx->srcpad, list);
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
return ret;
}
rtprtxsend: run a new GstTask on the src pad The reason behind this is to minimize the retransmission delay. Previously, when a NACK was received, rtprtxsend would put a retransmission packet in a queue and it would send it from chain(), i.e. only after a new buffer would arrive. This unfortunately was causing big delays, in the order of 60-100 ms, which can be critical for the receiver side. By having a separate GstTask for pushing buffers out of rtxsend, we can push buffers out right after receiving the event, without waiting for chain() to get called.
2014-01-15 08:46:14 +00:00
static void
gst_rtp_rtx_send_src_loop (GstRtpRtxSend * rtx)
{
GstDataQueueItem *data;
if (gst_data_queue_pop (rtx->queue, &data)) {
GST_LOG_OBJECT (rtx, "pushing rtx buffer %p", data->object);
rtprtxsend: ensure that no rtx buffers are sent after EOS To do that, enqueue the EOS event to be sent from the srcpad task thread and flush the queue right afterwards, so that no more rtx buffers can be sent, even if there are more requests coming in. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=722370
2014-01-21 12:42:38 +00:00
if (G_LIKELY (GST_IS_BUFFER (data->object))) {
GST_OBJECT_LOCK (rtx);
rtprtxsend: Update statistics before pushing If an element queries the number of retransmission buffers pushed *while* the push is still taking place (and before the object lock is taken just after) it would end up with the wrong statistic being reported. Increment it just before the push, avoids races when getting statistics https://bugzilla.gnome.org/show_bug.cgi?id=768723
2016-11-27 10:14:13 +00:00
/* Update statistics just before pushing. */
rtprtxsend: ensure that no rtx buffers are sent after EOS To do that, enqueue the EOS event to be sent from the srcpad task thread and flush the queue right afterwards, so that no more rtx buffers can be sent, even if there are more requests coming in. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=722370
2014-01-21 12:42:38 +00:00
rtx->num_rtx_packets++;
GST_OBJECT_UNLOCK (rtx);
rtprtxsend: Update statistics before pushing If an element queries the number of retransmission buffers pushed *while* the push is still taking place (and before the object lock is taken just after) it would end up with the wrong statistic being reported. Increment it just before the push, avoids races when getting statistics https://bugzilla.gnome.org/show_bug.cgi?id=768723
2016-11-27 10:14:13 +00:00
gst_pad_push (rtx->srcpad, GST_BUFFER (data->object));
rtprtxsend: ensure that no rtx buffers are sent after EOS To do that, enqueue the EOS event to be sent from the srcpad task thread and flush the queue right afterwards, so that no more rtx buffers can be sent, even if there are more requests coming in. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=722370
2014-01-21 12:42:38 +00:00
} else if (GST_IS_EVENT (data->object)) {
gst_pad_push_event (rtx->srcpad, GST_EVENT (data->object));
rtprtxsend: run a new GstTask on the src pad The reason behind this is to minimize the retransmission delay. Previously, when a NACK was received, rtprtxsend would put a retransmission packet in a queue and it would send it from chain(), i.e. only after a new buffer would arrive. This unfortunately was causing big delays, in the order of 60-100 ms, which can be critical for the receiver side. By having a separate GstTask for pushing buffers out of rtxsend, we can push buffers out right after receiving the event, without waiting for chain() to get called.
2014-01-15 08:46:14 +00:00
rtprtxsend: ensure that no rtx buffers are sent after EOS To do that, enqueue the EOS event to be sent from the srcpad task thread and flush the queue right afterwards, so that no more rtx buffers can be sent, even if there are more requests coming in. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=722370
2014-01-21 12:42:38 +00:00
/* after EOS, we should not send any more buffers,
* even if there are more requests coming in */
if (GST_EVENT_TYPE (data->object) == GST_EVENT_EOS) {
gst_rtp_rtx_send_set_flushing (rtx, TRUE);
}
} else {
g_assert_not_reached ();
}
rtprtxsend: run a new GstTask on the src pad The reason behind this is to minimize the retransmission delay. Previously, when a NACK was received, rtprtxsend would put a retransmission packet in a queue and it would send it from chain(), i.e. only after a new buffer would arrive. This unfortunately was causing big delays, in the order of 60-100 ms, which can be critical for the receiver side. By having a separate GstTask for pushing buffers out of rtxsend, we can push buffers out right after receiving the event, without waiting for chain() to get called.
2014-01-15 08:46:14 +00:00
data->object = NULL; /* we no longer own that object */
data->destroy (data);
} else {
GST_LOG_OBJECT (rtx, "flushing");
gst_pad_pause_task (rtx->srcpad);
}
}
static gboolean
gst_rtp_rtx_send_activate_mode (GstPad * pad, GstObject * parent,
GstPadMode mode, gboolean active)
{
GstRtpRtxSend *rtx = GST_RTP_RTX_SEND (parent);
gboolean ret = FALSE;
switch (mode) {
case GST_PAD_MODE_PUSH:
if (active) {
gst_rtp_rtx_send_set_flushing (rtx, FALSE);
ret = gst_pad_start_task (rtx->srcpad,
(GstTaskFunction) gst_rtp_rtx_send_src_loop, rtx, NULL);
} else {
gst_rtp_rtx_send_set_flushing (rtx, TRUE);
ret = gst_pad_stop_task (rtx->srcpad);
}
GST_INFO_OBJECT (rtx, "activate_mode: active %d, ret %d", active, ret);
break;
default:
break;
}
return ret;
}
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
static void
gst_rtp_rtx_send_get_property (GObject * object,
guint prop_id, GValue * value, GParamSpec * pspec)
{
GstRtpRtxSend *rtx = GST_RTP_RTX_SEND (object);
switch (prop_id) {
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
case PROP_PAYLOAD_TYPE_MAP:
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_LOCK (rtx);
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
g_value_set_boxed (value, rtx->rtx_pt_map_structure);
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_UNLOCK (rtx);
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
break;
case PROP_MAX_SIZE_TIME:
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_LOCK (rtx);
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
g_value_set_uint (value, rtx->max_size_time);
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_UNLOCK (rtx);
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
break;
case PROP_MAX_SIZE_PACKETS:
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_LOCK (rtx);
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
g_value_set_uint (value, rtx->max_size_packets);
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_UNLOCK (rtx);
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
break;
case PROP_NUM_RTX_REQUESTS:
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_LOCK (rtx);
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
g_value_set_uint (value, rtx->num_rtx_requests);
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_UNLOCK (rtx);
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
break;
case PROP_NUM_RTX_PACKETS:
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_LOCK (rtx);
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
g_value_set_uint (value, rtx->num_rtx_packets);
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_UNLOCK (rtx);
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
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
}
}
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
static gboolean
structure_to_hash_table (GQuark field_id, const GValue * value, gpointer hash)
{
const gchar *field_str;
guint field_uint;
guint value_uint;
field_str = g_quark_to_string (field_id);
field_uint = atoi (field_str);
value_uint = g_value_get_uint (value);
g_hash_table_insert ((GHashTable *) hash, GUINT_TO_POINTER (field_uint),
GUINT_TO_POINTER (value_uint));
return TRUE;
}
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
static void
gst_rtp_rtx_send_set_property (GObject * object,
guint prop_id, const GValue * value, GParamSpec * pspec)
{
GstRtpRtxSend *rtx = GST_RTP_RTX_SEND (object);
switch (prop_id) {
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
case PROP_SSRC_MAP:
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_LOCK (rtx);
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
if (rtx->external_ssrc_map)
gst_structure_free (rtx->external_ssrc_map);
rtx->external_ssrc_map = g_value_dup_boxed (value);
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_UNLOCK (rtx);
rtprtxsend: Add an rtx-ssrc property to allow external control of the ssrc This is useful when one needs to know the SSRC beforehands, so that it can be used for SRTP for example.
2013-11-25 14:00:45 +00:00
break;
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
case PROP_PAYLOAD_TYPE_MAP:
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_LOCK (rtx);
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
if (rtx->rtx_pt_map_structure)
gst_structure_free (rtx->rtx_pt_map_structure);
rtx->rtx_pt_map_structure = g_value_dup_boxed (value);
g_hash_table_remove_all (rtx->rtx_pt_map);
gst_structure_foreach (rtx->rtx_pt_map_structure, structure_to_hash_table,
rtx->rtx_pt_map);
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_UNLOCK (rtx);
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
break;
case PROP_MAX_SIZE_TIME:
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_LOCK (rtx);
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
rtx->max_size_time = g_value_get_uint (value);
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_UNLOCK (rtx);
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
break;
case PROP_MAX_SIZE_PACKETS:
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_LOCK (rtx);
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
rtx->max_size_packets = g_value_get_uint (value);
rtprtxsend: use the GstObject lock instead of a new one
2014-01-14 10:45:52 +00:00
GST_OBJECT_UNLOCK (rtx);
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
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
}
}
static GstStateChangeReturn
gst_rtp_rtx_send_change_state (GstElement * element, GstStateChange transition)
{
GstStateChangeReturn ret;
GstRtpRtxSend *rtx;
rtx = GST_RTP_RTX_SEND (element);
switch (transition) {
default:
break;
}
ret =
GST_ELEMENT_CLASS (gst_rtp_rtx_send_parent_class)->change_state (element,
transition);
switch (transition) {
case GST_STATE_CHANGE_PAUSED_TO_READY:
rtprtxsend: remove unused parameter from the internal reset() method
2014-01-14 11:38:51 +00:00
gst_rtp_rtx_send_reset (rtx);
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
break;
default:
break;
}
return ret;
}
gboolean
gst_rtp_rtx_send_plugin_init (GstPlugin * plugin)
{
GST_DEBUG_CATEGORY_INIT (gst_rtp_rtx_send_debug, "rtprtxsend", 0,
"rtp retransmission sender");
return gst_element_register (plugin, "rtprtxsend", GST_RANK_NONE,
GST_TYPE_RTP_RTX_SEND);
}
Reference in a new issue Copy permalink