Commit graph

17 commits

Author SHA1 Message Date
Mischa Spiegelmock
cdd7091c1c docs: Minor fixes in various places
https://bugzilla.gnome.org/show_bug.cgi?id=756996
2015-10-23 10:42:19 +03:00
Luis de Bethencourt
671b4d25cd remove unused enum items PROP_LAST
This were probably added to the enums due to cargo cult programming and are
unused. Removing them.
2015-04-24 17:01:12 +01:00
Sebastian Dröge
68dfe93463 rtxreceive: Put debug output for retransmission requests at the right place
Before it was only ever printed once for every time a ssrc was associated with
a specific stream.
2015-04-22 19:51:18 +02:00
Sebastian Dröge
caa255d2ed rtprtx*: Fix typos 2015-04-14 19:08:38 +02:00
Olivier Crête
ccac1f8c0b rtprtxreceive: Use offset when copying header
The header is not always at the start of the packet, so we need to compute
the offset first.
2014-11-29 18:38:12 -05:00
Sanjay NM
26a1344f37 Miscellaneous minor cleanups
Fix redundant variables and assignments,
and unreachable breaks.

https://bugzilla.gnome.org/show_bug.cgi?id=736875
https://bugzilla.gnome.org/show_bug.cgi?id=736876
https://bugzilla.gnome.org/show_bug.cgi?id=736879
https://bugzilla.gnome.org/show_bug.cgi?id=736880
https://bugzilla.gnome.org/show_bug.cgi?id=736881
https://bugzilla.gnome.org/show_bug.cgi?id=736888
https://bugzilla.gnome.org/show_bug.cgi?id=736890
https://bugzilla.gnome.org/show_bug.cgi?id=736892
https://bugzilla.gnome.org/show_bug.cgi?id=736893
https://bugzilla.gnome.org/show_bug.cgi?id=736894
2014-09-24 00:45:31 +01:00
Olivier Crête
b2a52035bf 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-04 22:36:59 -04:00
Tim-Philipp Müller
c9597298f9 docs: remove outdated and pointless 'Last reviewed' lines from docs
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
2014-04-26 23:35:17 +01:00
Wim Taymans
ef20dfe031 rtxreceive: copy flags and timestamps from original buffer 2014-01-21 15:29:27 +01:00
George Kiagiadakis
75859ae924 rtprtxreceive: remove stupid mutex unlock in the middle of chain() 2014-01-15 10:13:11 +01:00
George Kiagiadakis
bf347dc50c rtprtxreceive: use GST_DEBUG_OBJECT / GST_WARNING_OBJECT instead of GST_DEBUG / g_warning 2014-01-15 10:13:11 +01:00
George Kiagiadakis
47788929d3 rtprtxreceive: fix integer format specifiers in GST_DEBUG
seqnum in this function is 32-bit, so G_GUINT16_FORMAT would
produce undefined output on big endian systems
2014-01-15 10:13:11 +01:00
George Kiagiadakis
8a0ae00ea8 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-15 10:13:11 +01:00
George Kiagiadakis
513ffc45b5 rtprtxreceive: simplify the code of finalize() 2014-01-15 10:13:11 +01:00
George Kiagiadakis
0fdae5f2f7 rtprtxreceive: use the GstObject lock instead of a new one 2014-01-15 10:13:11 +01:00
George Kiagiadakis
9226091235 rtprtxreceive: modify to use a payload-type map like rtprtxsend 2014-01-03 20:48:29 +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