mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-11-06 17:39:47 +00:00
Code Issues 1 Projects Releases Wiki Activity
gstreamer/subprojects/gst-plugins-good/gst/rtpmanager/gstrtprtxreceive.h

84 lines
2.7 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 receiver element for GStreamer
*
* gstrtprtxreceive.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_RECEIVE_H__
#define __GST_RTP_RTX_RECEIVE_H__
#include <gst/gst.h>
#include <gst/rtp/gstrtpbuffer.h>
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/1890>
2021-02-08 20:40:19 +00:00
typedef struct _GstRtpRtxReceive GstRtpRtxReceive;
typedef struct _GstRtpRtxReceiveClass GstRtpRtxReceiveClass;
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_RECEIVE (gst_rtp_rtx_receive_get_type())
#define GST_RTP_RTX_RECEIVE(obj) (G_TYPE_CHECK_INSTANCE_CAST((obj),GST_TYPE_RTP_RTX_RECEIVE, GstRtpRtxReceive))
#define GST_RTP_RTX_RECEIVE_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST((klass),GST_TYPE_RTP_RTX_RECEIVE, GstRtpRtxReceiveClass))
#define GST_RTP_RTX_RECEIVE_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), GST_TYPE_RTP_RTX_RECEIVE, GstRtpRtxReceiveClass))
#define GST_IS_RTP_RTX_RECEIVE(obj) (G_TYPE_CHECK_INSTANCE_TYPE((obj),GST_TYPE_RTP_RTX_RECEIVE))
#define GST_IS_RTP_RTX_RECEIVE_CLASS(obj) (G_TYPE_CHECK_CLASS_TYPE((klass),GST_TYPE_RTP_RTX_RECEIVE))
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/1890>
2021-02-08 20:40:19 +00:00
#define GST_RTP_RTX_RECEIVE_CAST(obj) ((GstRtpRtxReceive *)(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 _GstRtpRtxReceive
{
GstElement element;
/* pad */
GstPad *sinkpad;
GstPad *srcpad;
/* retrieve associated master stream from rtx stream
* it also works to retrieve rtx stream from master stream
* as we make sure all ssrc are unique */
GHashTable *ssrc2_ssrc1_map;
/* contains seqnum of request packets of whom their ssrc have
* not been associated to a rtx stream yet */
GHashTable *seqnum_ssrc1_map;
rtprtxreceive: modify to use a payload-type map like rtprtxsend
2013-11-29 18:35:44 +00:00
/* rtx pt (uint) -> origin pt (uint) */
GHashTable *rtx_pt_map;
/* origin pt (string) -> rtx pt (uint) */
rtprtxreceive: 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:07:58 +00:00
GstStructure *rtx_pt_map_structure;
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
/* statistics */
guint num_rtx_requests;
guint num_rtx_packets;
guint num_rtx_assoc_packets;
rtprtxreceive: Wait until timeout to clear association requests If two streams request a retranmission for the same SSRC, ignore the second one if the first oen is less than one second old, otherwise time out the first one and ignore the second.
2014-05-05 02:32:54 +00:00
GstClockTime last_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
};
struct _GstRtpRtxReceiveClass
{
GstElementClass parent_class;
};
GType gst_rtp_rtx_receive_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 (rtprtxreceive);
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_RECEIVE_H__ */
Reference in a new issue Copy permalink