Commit graph

33 commits

Author SHA1 Message Date
George Kiagiadakis
286e1e62be rtprtx{send,receive}: improve the debug messages
* use INFO/DEBUG/LOG/TRACE equaly and meaningfully;
  previously rtprtxsend:LOG and rtprtxreceive:LOG would generate
  a totally different amount of log traffic and sometimes it was
  impossible to see the information you wanted without useless
  spam being printed around
* improve the wording, give a reasonable and self-explanatory
  amount of information
* print SSRCs in hex
* avoid G_FOO_FORMAT for readability (we are just printing integers)
2017-09-07 14:43:32 +03:00
George Kiagiadakis
1622d4c894 rtprtxsend: convert LOG message to TRACE
This is printed too often (for every chained buffer!) and just clutters the logs.
2017-03-16 17:46:46 +02:00
Edward Hervey
91f5b4eaa2 rtprtxsend: Update statistics before pushing
If an element queries the number of retransmission buffers pushed
*while* the push is still taking place (and before the object lock
is taken just after) it would end up with the wrong statistic
being reported.

Increment it just before the push, avoids races when getting statistics

https://bugzilla.gnome.org/show_bug.cgi?id=768723
2016-11-27 11:15:49 +01:00
Vineeth TM
1071309870 good: use new gst_element_class_add_static_pad_template()
https://bugzilla.gnome.org/show_bug.cgi?id=763076
2016-03-24 14:32:20 +02:00
Hyunjun Ko
b0d6020862 rtprtxsend: print valid type where guint32 is expected
https://bugzilla.gnome.org/show_bug.cgi?id=746445
2015-08-06 01:39:43 -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
80268e7d37 rtpsource/rtprtxsend: Also pass correct seqnum-offset and payload to the RTX rtpsource
https://bugzilla.gnome.org/show_bug.cgi?id=747394
2015-04-16 17:33:37 +02:00
Arun Raghavan
26bec72e52 rtpsession: Track RTX ssrc caps
This is needed so that we can generate SR for RTX stream correctly (the
clock rate is required).

https://bugzilla.gnome.org/show_bug.cgi?id=747394
2015-04-16 17:33:37 +02:00
Sebastian Dröge
17c6532b75 rtprtxsend: Copy over timestamps from the orignal buffers to the RTX buffers
https://bugzilla.gnome.org/show_bug.cgi?id=747394
2015-04-16 17:33:37 +02:00
Sebastian Dröge
caa255d2ed rtprtx*: Fix typos 2015-04-14 19:08:38 +02:00
Sebastian Dröge
1018aacb35 rtprtxsend: Add support for buffer lists 2015-03-19 11:54:37 +01:00
Sebastian Dröge
27cf71e209 rtprtxsend: Require clock-rate in the caps and handle no ssrc in the caps properly 2014-04-17 17:58:58 +02:00
Sebastian Dröge
3bc53f0840 rtprtxsend: Fix unitialized variable compiler warning
variable 'rtx_ssrc' is used uninitialized whenever
'if' condition is false [-Werror,-Wsometimes-uninitialized]
2014-02-08 17:24:06 +01:00
George Kiagiadakis
1a300eb509 rtprtxsend: ensure that no rtx buffers are sent after EOS
To do that, enqueue the EOS event to be sent from the srcpad task
thread and flush the queue right afterwards, so that no more rtx
buffers can be sent, even if there are more requests coming in.

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=722370
2014-01-21 15:00:37 +01:00
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
397c4ed7a0 rtprtxsend: remove wrong check for payload type not having been set
1) pt can be lower than 96
2) there is no point in checking that because rtprtxsend will not
   even store buffers for payload types that it doesn't know about,
   so this case will never be reached
2014-01-15 10:13:12 +01:00
George Kiagiadakis
55746eaa4c rtprtxsend: fix data locking when creating rtx packets
This patch moves the creation of rtx packets to be done early,
in the src_event() function, when they are requested. The purpose
is to run gst_rtp_rtx_buffer_new() with the object locked to
protect internal data, because if it is done at the pushing stage,
we would have to lock and unlock multiple times in a row while we
are pushing the rtx buffers.

Previously there was no locking at all, which was terribly wrong.
2014-01-15 10:13:11 +01:00
George Kiagiadakis
3d9ca102c9 rtprtxsend: lock access to internal data in sink_event() function 2014-01-15 10:13:11 +01:00
George Kiagiadakis
ee8ae3000e rtprtxsend: remove unnecessary call to reset() from finalize()
...and use _free_full() on the pending buffers queue now that
reset() is not being called
2014-01-15 10:13:11 +01:00
George Kiagiadakis
f9f7e6e721 rtprtxsend: remove unused parameter from the internal reset() method 2014-01-15 10:13:11 +01:00
George Kiagiadakis
6d588ad6bb rtprtxsend: Use g_slice_* for allocating internal structures 2014-01-15 10:13:11 +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
Tim-Philipp Müller
335b619cd5 rtprtxsend: remove duplicate assignment
Coverity CID 1151680
2014-01-09 23:55:16 +00:00
George Kiagiadakis
c8a04bc7b2 rtprtxsend: do not keep history of packets with an unknown payload type
This allows to disable retransmission per payload type by not putting
a certain payload type in the map.
2014-01-03 20:48:29 +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
41285697ac rtprtxsend: Add an rtx-ssrc property to allow external control of the ssrc
This is useful when one needs to know the SSRC beforehands, so that it can
be used for SRTP for example.
2014-01-03 20:48:29 +01:00
George Kiagiadakis
0a8b149e9e rtprtxsend: use a realistic limit for the value of max-size-packets
G_MAXINT16 is chosen because if the queue contains more than
G_MAXINT16 packets, seqnum comparison will not work properly.
2014-01-03 20:48:28 +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
George Kiagiadakis
920a55532c rtprtxsend: keep important buffer information in a private structure
This is to avoid mapping a buffer every time we need to read a seqnum
or a timestamp.
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