mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-12-18 14:26:43 +00:00
Code Issues 1 Projects Releases Wiki Activity
gstreamer/subprojects/gst-plugins-good/gst/rtpmanager/gstrtprtxsend.c

1005 lines
32 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
docs: Port all docstring to gtk-doc markdown
2018-10-22 09:39:24 +00:00
* @title: rtprtxsend
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
*
* See #GstRtpRtxReceive for examples
docs: Port all docstring to gtk-doc markdown
2018-10-22 09:39:24 +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
* 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,
rtprtxsend: allow generic input caps When connected to an upstream rtpfunnel element, payload-type, ssrc and clock-rate will not be present in the received caps. rtprtxsend can already deal with only the clock rate being present there, a new property is exposed to allow users to provide a payload-type -> clock-rate map, this enables the use of the max-size-time property for bundled streams.
2020-01-27 22:59:05 +00:00
PROP_NUM_RTX_PACKETS,
PROP_CLOCK_RATE_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
};
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: allow generic input caps When connected to an upstream rtpfunnel element, payload-type, ssrc and clock-rate will not be present in the received caps. rtprtxsend can already deal with only the clock rate being present there, a new property is exposed to allow users to provide a payload-type -> clock-rate map, this enables the use of the max-size-time property for bundled streams.
2020-01-27 22:59:05 +00:00
GST_STATIC_CAPS ("application/x-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
);
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);
rtpmanager: allow per feature registration Split plugin into features including dynamic types which can be indiviually registered during a static build. More details here: https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/199 https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/661 Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/876>
2021-02-16 13:24:33 +00:00
G_DEFINE_TYPE_WITH_CODE (GstRtpRtxSend, gst_rtp_rtx_send, GST_TYPE_ELEMENT,
GST_DEBUG_CATEGORY_INIT (gst_rtp_rtx_send_debug, "rtprtxsend", 0,
"rtp retransmission sender"));
GST_ELEMENT_REGISTER_DEFINE (rtprtxsend, "rtprtxsend", GST_RANK_NONE,
GST_TYPE_RTP_RTX_SEND);
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
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));
rtprtxsend: allow generic input caps When connected to an upstream rtpfunnel element, payload-type, ssrc and clock-rate will not be present in the received caps. rtprtxsend can already deal with only the clock rate being present there, a new property is exposed to allow users to provide a payload-type -> clock-rate map, this enables the use of the max-size-time property for bundled streams.
2020-01-27 22:59:05 +00:00
g_object_class_install_property (gobject_class, PROP_CLOCK_RATE_MAP,
g_param_spec_boxed ("clock-rate-map", "Clock Rate Map",
"Map of payload types to their clock rates",
GST_TYPE_STRUCTURE, G_PARAM_READWRITE | 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)
{
rtprtx: don't access type-system per buffer When doing only a single stream of audio/video this hardly matters, but when doing many at the same time, the fact that you have to get a hold of the glib global type-system lock every time you process a buffer, means that there is a limit to how many streams you can process in parallel. Luckily the fix is very simple, by doing a cast rather than a full type-check. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1873>
2021-02-08 20:40:19 +00:00
GstRtpRtxSend *rtx = GST_RTP_RTX_SEND_CAST (object);
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
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: allow generic input caps When connected to an upstream rtpfunnel element, payload-type, ssrc and clock-rate will not be present in the received caps. rtprtxsend can already deal with only the clock rate being present there, a new property is exposed to allow users to provide a payload-type -> clock-rate map, this enables the use of the max-size-time property for bundled streams.
2020-01-27 22:59:05 +00:00
g_hash_table_unref (rtx->clock_rate_map);
if (rtx->clock_rate_map_structure)
gst_structure_free (rtx->clock_rate_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);
rtprtxsend: allow generic input caps When connected to an upstream rtpfunnel element, payload-type, ssrc and clock-rate will not be present in the received caps. rtprtxsend can already deal with only the clock rate being present there, a new property is exposed to allow users to provide a payload-type -> clock-rate map, this enables the use of the max-size-time property for bundled streams.
2020-01-27 22:59:05 +00:00
rtx->clock_rate_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)
{
rtprtx: don't access type-system per buffer When doing only a single stream of audio/video this hardly matters, but when doing many at the same time, the fact that you have to get a hold of the glib global type-system lock every time you process a buffer, means that there is a limit to how many streams you can process in parallel. Luckily the fix is very simple, by doing a cast rather than a full type-check. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1873>
2021-02-08 20:40:19 +00:00
GstRtpRtxSend *rtx = GST_RTP_RTX_SEND_CAST (parent);
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
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
}
rtprtxsend: Improve looging of not found RTX packet When an RTX packet is not found, display a message that say if the packet have not arrived yet or if it was already removed from the RTX packet queue.
2019-03-20 19:45:35 +00:00
#ifndef GST_DISABLE_DEBUG
else {
BufferQueueItem *item = NULL;
iter = g_sequence_get_begin_iter (data->queue);
if (!g_sequence_iter_is_end (iter))
item = g_sequence_get (iter);
if (item && seqnum < item->seqnum) {
GST_DEBUG_OBJECT (rtx, "requested seqnum %u has already been "
"removed from the rtx queue; the first available is %u",
seqnum, item->seqnum);
} else {
GST_WARNING_OBJECT (rtx, "requested seqnum %u has not been "
"transmitted yet in the original stream; either the remote end "
"is not configured correctly, or the source is too slow",
seqnum);
}
}
#endif
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
documentation: fix a number of typos
2019-09-02 12:27:35 +00:00
/* choose another ssrc for our retransmitted 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)
{
rtprtx: don't access type-system per buffer When doing only a single stream of audio/video this hardly matters, but when doing many at the same time, the fact that you have to get a hold of the glib global type-system lock every time you process a buffer, means that there is a limit to how many streams you can process in parallel. Luckily the fix is very simple, by doing a cast rather than a full type-check. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1873>
2021-02-08 20:40:19 +00:00
GstRtpRtxSend *rtx = GST_RTP_RTX_SEND_CAST (parent);
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
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;
rtprtxsend: allow generic input caps When connected to an upstream rtpfunnel element, payload-type, ssrc and clock-rate will not be present in the received caps. rtprtxsend can already deal with only the clock rate being present there, a new property is exposed to allow users to provide a payload-type -> clock-rate map, this enables the use of the max-size-time property for bundled streams.
2020-01-27 22:59:05 +00:00
if (payload == -1 || ssrc == G_MAXUINT)
break;
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 (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);
rtprtxsend: don't process or warn if no map is set This makes it more gentle when doing "pass-through" Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1879>
2016-06-22 12:48:59 +00:00
if (rtx->rtx_pt_map_structure && GPOINTER_TO_INT (rtx_payload) == -1
&& payload != -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
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
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
rtprtxsend: if no rtx is present, don't expose a rtx-ssrc in caps The point here is that rtpsession will create a new rtpsource when the field "rtx-ssrc" is present, and when not doing rtx, that means a random ssrc will create a new rtpsource that will be included in RTCP messages for the current session. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1882>
2021-02-01 15:07:08 +00:00
/* The session might need to know the RTX ssrc */
if (GPOINTER_TO_INT (rtx_payload) != -1) {
gst_caps_set_simple (caps, "rtx-ssrc", G_TYPE_UINT, data->rtx_ssrc,
"rtx-seqnum-offset", G_TYPE_UINT, data->seqnum_base, NULL);
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-payload", G_TYPE_INT,
GPOINTER_TO_INT (rtx_payload), NULL);
rtprtxsend: if no rtx is present, don't expose a rtx-ssrc in caps The point here is that rtpsession will create a new rtpsource when the field "rtx-ssrc" is present, and when not doing rtx, that means a random ssrc will create a new rtpsource that will be included in RTCP messages for the current session. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1882>
2021-02-01 15:07:08 +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
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);
rtprtxsend: allow generic input caps When connected to an upstream rtpfunnel element, payload-type, ssrc and clock-rate will not be present in the received caps. rtprtxsend can already deal with only the clock rate being present there, a new property is exposed to allow users to provide a payload-type -> clock-rate map, this enables the use of the max-size-time property for bundled streams.
2020-01-27 22:59:05 +00:00
if (data->clock_rate == 0 && rtx->clock_rate_map_structure) {
data->clock_rate =
GPOINTER_TO_INT (g_hash_table_lookup (rtx->clock_rate_map,
GUINT_TO_POINTER (payload_type)));
}
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
/* 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)
{
rtprtx: don't access type-system per buffer When doing only a single stream of audio/video this hardly matters, but when doing many at the same time, the fact that you have to get a hold of the glib global type-system lock every time you process a buffer, means that there is a limit to how many streams you can process in parallel. Luckily the fix is very simple, by doing a cast rather than a full type-check. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1873>
2021-02-08 20:40:19 +00:00
GstRtpRtxSend *rtx = GST_RTP_RTX_SEND_CAST (parent);
rtprtxsend: Add support for buffer lists
2015-03-19 10:54:12 +00:00
GstFlowReturn ret;
GST_OBJECT_LOCK (rtx);
rtprtxsend: don't process or warn if no map is set This makes it more gentle when doing "pass-through" Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1879>
2016-06-22 12:48:59 +00:00
if (rtx->rtx_pt_map_structure)
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)
{
rtprtx: don't access type-system per buffer When doing only a single stream of audio/video this hardly matters, but when doing many at the same time, the fact that you have to get a hold of the glib global type-system lock every time you process a buffer, means that there is a limit to how many streams you can process in parallel. Luckily the fix is very simple, by doing a cast rather than a full type-check. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1873>
2021-02-08 20:40:19 +00:00
GstRtpRtxSend *rtx = GST_RTP_RTX_SEND_CAST (parent);
rtprtxsend: Add support for buffer lists
2015-03-19 10:54:12 +00:00
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)
{
rtprtx: don't access type-system per buffer When doing only a single stream of audio/video this hardly matters, but when doing many at the same time, the fact that you have to get a hold of the glib global type-system lock every time you process a buffer, means that there is a limit to how many streams you can process in parallel. Luckily the fix is very simple, by doing a cast rather than a full type-check. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1873>
2021-02-08 20:40:19 +00:00
GstRtpRtxSend *rtx = GST_RTP_RTX_SEND_CAST (parent);
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
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)
{
rtprtx: don't access type-system per buffer When doing only a single stream of audio/video this hardly matters, but when doing many at the same time, the fact that you have to get a hold of the glib global type-system lock every time you process a buffer, means that there is a limit to how many streams you can process in parallel. Luckily the fix is very simple, by doing a cast rather than a full type-check. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1873>
2021-02-08 20:40:19 +00:00
GstRtpRtxSend *rtx = GST_RTP_RTX_SEND_CAST (object);
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
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;
rtprtxsend: allow generic input caps When connected to an upstream rtpfunnel element, payload-type, ssrc and clock-rate will not be present in the received caps. rtprtxsend can already deal with only the clock rate being present there, a new property is exposed to allow users to provide a payload-type -> clock-rate map, this enables the use of the max-size-time property for bundled streams.
2020-01-27 22:59:05 +00:00
case PROP_CLOCK_RATE_MAP:
GST_OBJECT_LOCK (rtx);
g_value_set_boxed (value, rtx->clock_rate_map_structure);
GST_OBJECT_UNLOCK (rtx);
break;
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:
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)
{
rtprtx: don't access type-system per buffer When doing only a single stream of audio/video this hardly matters, but when doing many at the same time, the fact that you have to get a hold of the glib global type-system lock every time you process a buffer, means that there is a limit to how many streams you can process in parallel. Luckily the fix is very simple, by doing a cast rather than a full type-check. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1873>
2021-02-08 20:40:19 +00:00
GstRtpRtxSend *rtx = GST_RTP_RTX_SEND_CAST (object);
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
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;
rtprtxsend: allow generic input caps When connected to an upstream rtpfunnel element, payload-type, ssrc and clock-rate will not be present in the received caps. rtprtxsend can already deal with only the clock rate being present there, a new property is exposed to allow users to provide a payload-type -> clock-rate map, this enables the use of the max-size-time property for bundled streams.
2020-01-27 22:59:05 +00:00
case PROP_CLOCK_RATE_MAP:
GST_OBJECT_LOCK (rtx);
if (rtx->clock_rate_map_structure)
gst_structure_free (rtx->clock_rate_map_structure);
rtx->clock_rate_map_structure = g_value_dup_boxed (value);
g_hash_table_remove_all (rtx->clock_rate_map);
gst_structure_foreach (rtx->clock_rate_map_structure,
structure_to_hash_table, rtx->clock_rate_map);
GST_OBJECT_UNLOCK (rtx);
break;
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:
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;
rtprtx: don't access type-system per buffer When doing only a single stream of audio/video this hardly matters, but when doing many at the same time, the fact that you have to get a hold of the glib global type-system lock every time you process a buffer, means that there is a limit to how many streams you can process in parallel. Luckily the fix is very simple, by doing a cast rather than a full type-check. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1873>
2021-02-08 20:40:19 +00:00
rtx = GST_RTP_RTX_SEND_CAST (element);
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
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;
}
Reference in a new issue Copy permalink