rtprtxreceive

rtprtxreceive

Properties

guint num-rtx-requests Read
guint num-rtx-packets Read
guint num-rtx-assoc-packets Read
GstStructure * payload-type-map Read / Write

Types and Values

struct GstRtpRtxReceive

Object Hierarchy

    GObject
    ╰── GInitiallyUnowned
        ╰── GstObject
            ╰── GstElement
                ╰── GstRtpRtxReceive

Description

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 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. See GstRtpRtxSend

Example pipelines

1
2
3
4
5
6
 
gst-launch-1.0 rtpsession name=rtpsession \
        audiotestsrc ! speexenc ! rtpspeexpay pt=97 ! rtprtxsend rtx-payload-type=99 ! \
            identity drop-probability=0.1 ! rtpsession.send_rtp_sink \
            rtpsession.send_rtp_src ! udpsink host="127.0.0.1" port=5000 \
        udpsrc port=5001 ! rtpsession.recv_rtcp_sink \
        rtpsession.send_rtcp_src ! udpsink host="127.0.0.1" port=5002 sync=false async=false
Send audio stream through port 5000. (5001 and 5002 are just the rtcp link with the receiver) 
1
2
3
4
5
6
7
 
gst-launch-1.0 rtpsession name=rtpsession \
        udpsrc port=5000 caps="application/x-rtp,media=(string)audio,clock-rate=(int)44100,encoding-name=(string)SPEEX,encoding-params=(string)1,octet-align=(string)1" ! \
            rtpsession.recv_rtp_sink \
            rtpsession.recv_rtp_src ! rtprtxreceive rtx-payload-types="99" ! rtpjitterbuffer do-retransmission=true ! rtpspeexdepay ! \
            speexdec ! audioconvert ! autoaudiosink \
        rtpsession.send_rtcp_src ! udpsink host="127.0.0.1" port=5001 \
        udpsrc port=5002 ! rtpsession.recv_rtcp_sink sync=fakse async=false
Receive audio stream from port 5000. (5001 and 5002 are just the rtcp link with the sender) On sender side make sure to use a different payload type for the stream and its associated retransmission stream (see GstRtpRtxSend). Note that several retransmission streams can have the same payload type so this is not deterministic. Actually the rtprtxreceiver element does the association using seqnum values. On receiver side set all the retransmission payload types (Those informations are retrieve through SDP). You should still hear a clear sound when setting drop-probability to something greater than 0. The rtpjitterbuffer will generate a custom upstream event GstRTPRetransmissionRequest when it assumes that one packet is missing. Then this request is translated to a FB NACK in the rtcp link Finally the rtpsession of the sender side re-convert it in a GstRTPRetransmissionRequest that will be handle by rtprtxsend. When increasing this value it may be possible that even the retransmission stream would be dropped so the receiver will ask to resend the packets again and again until it actually receive them. If the value is too high the rtprtxsend will not be able to retrieve the packet in its list of stored packets. For learning purpose you could try to increase the max-size-packets or max-size-time rtprtxsender's properties. Also note that you should use rtprtxsend through rtpbin and its set-aux-send property. See GstRtpBin. 
1
2
3
4
5
6
7
8
9
10
11
12
 
gst-launch-1.0 rtpsession name=rtpsession0 \
        audiotestsrc wave=0 ! speexenc ! rtpspeexpay pt=97 ! rtprtxsend rtx-payload-type=99 seqnum-offset=1 ! \
            identity drop-probability=0.1 ! rtpsession0.send_rtp_sink \
            rtpsession0.send_rtp_src ! udpsink host="127.0.0.1" port=5000 \
        udpsrc port=5001 ! rtpsession0.recv_rtcp_sink \
        rtpsession0.send_rtcp_src ! udpsink host="127.0.0.1" port=5002 sync=false async=false \
               rtpsession name=rtpsession1 \
        audiotestsrc wave=0 ! speexenc ! rtpspeexpay pt=97 ! rtprtxsend rtx-payload-type=99 seqnum-offset=10 ! \
            identity drop-probability=0.1 ! rtpsession1.send_rtp_sink \
            rtpsession1.send_rtp_src ! udpsink host="127.0.0.1" port=5000 \
        udpsrc port=5004 ! rtpsession1.recv_rtcp_sink \
        rtpsession1.send_rtcp_src ! udpsink host="127.0.0.1" port=5002 sync=false async=false
Send two audio streams to port 5000. 
1
2
3
4
5
6
7
8
 
gst-launch-1.0 rtpsession name=rtpsession
        udpsrc port=5000 caps="application/x-rtp,media=(string)audio,clock-rate=(int)44100,encoding-name=(string)SPEEX,encoding-params=(string)1,octet-align=(string)1" ! \
            rtpsession.recv_rtp_sink \
            rtpsession.recv_rtp_src ! rtprtxreceive rtx-payload-types="99" ! rtpssrcdemux name=demux \
            demux. ! queue ! rtpjitterbuffer do-retransmission=true ! rtpspeexdepay ! speexdec ! audioconvert ! autoaudiosink \
            demux. ! queue ! rtpjitterbuffer do-retransmission=true ! rtpspeexdepay ! speexdec ! audioconvert ! autoaudiosink \
        rtpsession.send_rtcp_src ! ! tee name=t ! queue ! udpsink host="127.0.0.1" port=5001 t. ! queue ! udpsink host="127.0.0.1" port=5004 \
        udpsrc port=5002 ! rtpsession.recv_rtcp_sink sync=fakse async=false
Receive audio stream from port 5000. On sender side the two streams have the same payload type for master streams, Same about retransmission streams. The streams are sent to the network through two distincts sessions. But we need to set a different seqnum-offset to make sure their seqnum navigate at a different rate like in concrete cases. We could also choose the same seqnum offset but we would require to set a different initial seqnum value. This is also why the rtprtxreceive can succeed to do the association between master and retransmission stream. On receiver side the same session is used to receive the two streams. So the rtpssrcdemux is here to demultiplex those two streams. The rtprtxreceive is responsible for reconstructing the original packets from the two retransmission streams. You can play with the drop-probability value for one or both streams. You should hear a clear sound. (after a few seconds the two streams wave feel synchronized)

Synopsis

Element Information

plugin

 rtpmanager

author

 Julien Isorce <julien.isorce@collabora.co.uk>

class

 Codec

Element Pads

name

 sink

direction

 sink

presence

 always

details

 application/x-rtp

name

 src

direction

 source

presence

 always

details

 application/x-rtp

Functions

Types and Values

struct GstRtpRtxReceive

struct GstRtpRtxReceive;

Property Details

The “num-rtx-requests” property

  “num-rtx-requests”         guint

Number of retransmission events received.

Flags: Read

Default value: 0

The “num-rtx-packets” property

  “num-rtx-packets”          guint

Number of retransmission packets received.

Flags: Read

Default value: 0

The “num-rtx-assoc-packets” property

  “num-rtx-assoc-packets”    guint

Number of retransmission packets correctly associated with retransmission requests.

Flags: Read

Default value: 0

The “payload-type-map” property

  “payload-type-map”         GstStructure *

Map of original payload types to their retransmission payload types.

Flags: Read / Write

See Also

rtprtxsend, rtpsession, rtpjitterbuffer

Generated by GTK-Doc V1.25