Commit graph

8 commits

Author SHA1 Message Date
George Kiagiadakis
133913a11a 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-21 14:54:01 +01:00
George Kiagiadakis
252dfc34c8 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-15 10:13:11 +01:00
George Kiagiadakis
c945200ff2 rtprtxsend: use the GstObject lock instead of a new one 2014-01-15 10:13:11 +01:00
Wim Taymans
130ad1b1fa rtprtxsend: Allow SSRC-multiplexing and multiple payload types in the original stream
Conflicts:
	tests/examples/rtp/server-rtpaux.c
2014-01-03 20:48:29 +01:00
George Kiagiadakis
51edc07127 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.
2014-01-03 20:48:28 +01:00
George Kiagiadakis
487fa8c989 rtprtxsend: retransmit packets in the same order as the rtx requests 2014-01-03 20:48:28 +01:00
George Kiagiadakis
7d530ab59f 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).
2014-01-03 20:48:28 +01:00
Julien Isorce
5a1aa75961 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
2014-01-03 20:47:59 +01:00