mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-11-26 11:41:09 +00:00
Code Issues 1 Projects Releases Wiki Activity
gstreamer/subprojects/gst-plugins-good/gst/rtpmanager/gstrtprtxsend.h

99 lines
2.9 KiB
C
Raw Normal View History

rtpmanager: add new rtprtxsend / rtprtxreceive elements The purpose of the sender RTX object is to keep a history of RTP packets up to a configurable limit (in time). It will listen for custom retransmission events from downstream. When it receives a request for retransmission, it will look up the requested seqnum in its list of stored packets. If the packet is available, it will create a RTX packet according to RFC 4588 and send this as an auxiliary stream. The receiver will listen to the custom retransmission events from the downstream jitterbuffer and will remember the SSRC1 of the stream and seqnum that was requested. When it sees a packet with one of the stored seqnum, it associates the SSRC2 of the stream with the SSRC1 of the master stream. From then on it knows that SSRC2 is the retransmission stream of SSRC1. This algorithm is stated in RFC 4588. For this algorithm to work, RFC4588 also states that no two pending retransmission requests can exist for the same seqnum and different SSRCs or else it would be impossible to associate the retransmission with the original requester SSRC. When the RTX receiver has associated the retransmission packets, it can depayload and forward them to the source pad of the element. RTX is SSRC-multiplexed Fixes https://bugzilla.gnome.org/show_bug.cgi?id=711084
2013-11-01 15:52:03 +00:00
/* RTP Retransmission sender element for GStreamer
*
* gstrtprtxsend.h:
*
* Copyright (C) 2013 Collabora Ltd.
* @author Julien Isorce <julien.isorce@collabora.co.uk>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Library General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Library General Public License for more details.
*
* You should have received a copy of the GNU Library General Public
* License along with this library; if not, write to the
* Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
* Boston, MA 02110-1301, USA.
*/
#ifndef __GST_RTP_RTX_SEND_H__
#define __GST_RTP_RTX_SEND_H__
#include <gst/gst.h>
rtpmanager/rtx: implement initial support for reading/writing rid extensions Two RTP Header extensions are very relevant for rtprtxsend/receive. 1. "urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id": will always be removed 2. "urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id": will be written instead of the "rtp-stream-id" header extension. Currently it's only a simple replacement of one header extension for another however a future change would only add the relevant extension based on some heuristics (like, video frames only on one of the rtp key frame buffers, or only until the rtx ssrc has been validated by the peer) in order to reduce the required bandwidth. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1759>
2021-09-09 13:43:33 +00:00
#include <gst/rtp/rtp.h>
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
#include <gst/base/gstdataqueue.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
G_BEGIN_DECLS
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
typedef struct _GstRtpRtxSend GstRtpRtxSend;
typedef struct _GstRtpRtxSendClass GstRtpRtxSendClass;
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
#define GST_TYPE_RTP_RTX_SEND (gst_rtp_rtx_send_get_type())
#define GST_RTP_RTX_SEND(obj) (G_TYPE_CHECK_INSTANCE_CAST((obj),GST_TYPE_RTP_RTX_SEND, GstRtpRtxSend))
#define GST_RTP_RTX_SEND_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST((klass),GST_TYPE_RTP_RTX_SEND, GstRtpRtxSendClass))
#define GST_RTP_RTX_SEND_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), GST_TYPE_RTP_RTX_SEND, GstRtpRtxSendClass))
#define GST_IS_RTP_RTX_SEND(obj) (G_TYPE_CHECK_INSTANCE_TYPE((obj),GST_TYPE_RTP_RTX_SEND))
#define GST_IS_RTP_RTX_SEND_CLASS(obj) (G_TYPE_CHECK_CLASS_TYPE((klass),GST_TYPE_RTP_RTX_SEND))
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
#define GST_RTP_RTX_SEND_CAST(obj) ((GstRtpRtxSend *)(obj))
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
struct _GstRtpRtxSend
{
GstElement element;
/* pad */
GstPad *sinkpad;
GstPad *srcpad;
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
/* rtp packets that will be pushed out */
GstDataQueue *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
rtprtxsend: Allow SSRC-multiplexing and multiple payload types in the original stream Conflicts: tests/examples/rtp/server-rtpaux.c
2014-01-02 14:18:52 +00:00
/* ssrc -> SSRCRtxData */
GHashTable *ssrc_data;
/* rtx ssrc -> master ssrc */
GHashTable *rtx_ssrcs;
rtpmanager: add new rtprtxsend / rtprtxreceive elements The purpose of the sender RTX object is to keep a history of RTP packets up to a configurable limit (in time). It will listen for custom retransmission events from downstream. When it receives a request for retransmission, it will look up the requested seqnum in its list of stored packets. If the packet is available, it will create a RTX packet according to RFC 4588 and send this as an auxiliary stream. The receiver will listen to the custom retransmission events from the downstream jitterbuffer and will remember the SSRC1 of the stream and seqnum that was requested. When it sees a packet with one of the stored seqnum, it associates the SSRC2 of the stream with the SSRC1 of the master stream. From then on it knows that SSRC2 is the retransmission stream of SSRC1. This algorithm is stated in RFC 4588. For this algorithm to work, RFC4588 also states that no two pending retransmission requests can exist for the same seqnum and different SSRCs or else it would be impossible to associate the retransmission with the original requester SSRC. When the RTX receiver has associated the retransmission packets, it can depayload and forward them to the source pad of the element. RTX is SSRC-multiplexed Fixes https://bugzilla.gnome.org/show_bug.cgi?id=711084
2013-11-01 15:52:03 +00:00
rtprtxsend: Allow SSRC-multiplexing and multiple payload types in the original stream Conflicts: tests/examples/rtp/server-rtpaux.c
2014-01-02 14:18:52 +00:00
/* master ssrc -> rtx ssrc (property) */
GstStructure *external_ssrc_map;
rtprtxsend: Handle the max_size_time property This property allows you to specify the amount of buffers to keep in the retransmission queue expressed as time (ms) instead of buffer count (which is the max_size_buffers property).
2013-10-29 17:27:00 +00:00
rtprtxsend: Allow SSRC-multiplexing and multiple payload types in the original stream Conflicts: tests/examples/rtp/server-rtpaux.c
2014-01-02 14:18:52 +00:00
/* orig pt (uint) -> rtx pt (uint) */
GHashTable *rtx_pt_map;
/* orig pt (string) -> rtx pt (uint) */
rtprtxsend: change the rtx_pt_map directly in set_property() instead of delaying it for chain() The same lock is held, so there is no point in complicating it...
2014-01-14 11:13:49 +00:00
GstStructure *rtx_pt_map_structure;
rtprtxsend: Handle the max_size_time property This property allows you to specify the amount of buffers to keep in the retransmission queue expressed as time (ms) instead of buffer count (which is the max_size_buffers property).
2013-10-29 17:27:00 +00:00
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
/* orig pt (uint) -> clock rate (uint) */
GHashTable *clock_rate_map;
/* orig pt (string) -> clock rate (uint) */
GstStructure *clock_rate_map_structure;
rtprtxsend: Handle the max_size_time property This property allows you to specify the amount of buffers to keep in the retransmission queue expressed as time (ms) instead of buffer count (which is the max_size_buffers property).
2013-10-29 17:27:00 +00:00
/* buffering control properties */
rtpmanager: add new rtprtxsend / rtprtxreceive elements The purpose of the sender RTX object is to keep a history of RTP packets up to a configurable limit (in time). It will listen for custom retransmission events from downstream. When it receives a request for retransmission, it will look up the requested seqnum in its list of stored packets. If the packet is available, it will create a RTX packet according to RFC 4588 and send this as an auxiliary stream. The receiver will listen to the custom retransmission events from the downstream jitterbuffer and will remember the SSRC1 of the stream and seqnum that was requested. When it sees a packet with one of the stored seqnum, it associates the SSRC2 of the stream with the SSRC1 of the master stream. From then on it knows that SSRC2 is the retransmission stream of SSRC1. This algorithm is stated in RFC 4588. For this algorithm to work, RFC4588 also states that no two pending retransmission requests can exist for the same seqnum and different SSRCs or else it would be impossible to associate the retransmission with the original requester SSRC. When the RTX receiver has associated the retransmission packets, it can depayload and forward them to the source pad of the element. RTX is SSRC-multiplexed Fixes https://bugzilla.gnome.org/show_bug.cgi?id=711084
2013-11-01 15:52:03 +00:00
guint max_size_time;
guint max_size_packets;
/* statistics */
guint num_rtx_requests;
guint num_rtx_packets;
rtpmanager/rtx: implement initial support for reading/writing rid extensions Two RTP Header extensions are very relevant for rtprtxsend/receive. 1. "urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id": will always be removed 2. "urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id": will be written instead of the "rtp-stream-id" header extension. Currently it's only a simple replacement of one header extension for another however a future change would only add the relevant extension based on some heuristics (like, video frames only on one of the rtp key frame buffers, or only until the rtx ssrc has been validated by the peer) in order to reduce the required bandwidth. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1759>
2021-09-09 13:43:33 +00:00
/* list of relevant RTP Header Extensions */
GstRTPHeaderExtension *rid_stream;
GstRTPHeaderExtension *rid_repaired;
GstBuffer *dummy_writable;
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
};
struct _GstRtpRtxSendClass
{
GstElementClass parent_class;
};
GType gst_rtp_rtx_send_get_type (void);
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
GST_ELEMENT_REGISTER_DECLARE (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
G_END_DECLS
#endif /* __GST_RTP_RTX_SEND_H__ */
Reference in a new issue Copy permalink