Commit graph

285 commits

Author SHA1 Message Date
Stian Selnes
85a56f8ee3 rtpsession: handle sdes messages with non-utf8 more gracefully 2016-08-25 18:28:44 -04:00
Miguel París Díaz
83f4c08747 rtpsession: take the lock when changing stats
https://bugzilla.gnome.org/show_bug.cgi?id=766025
2016-06-17 12:52:29 +03:00
Mikhail Fludkov
ee7e80d615 rtpsession: don't act on suspicious BYE RTCP
Some endpoints (like Tandberg E20) can send BYE packet containing our
internal SSRC. I this case we would detect SSRC collision and get rid
of the source at some point. But because we are still sending packets
with that SSRC the source will be recreated immediately.
This brand new internal source will not have some variables incorrectly
set in its state. For example 'seqnum-base` and `clock-rate` values will be
-1.
The fix is not to act on BYE RTCP if it contains internal or unknown
SSRC.

https://bugzilla.gnome.org/show_bug.cgi?id=762219
2016-05-20 09:28:39 +03:00
Sebastian Dröge
fe34f46f32 rtpsession: Take the lock already when reading the other stats, not just for the hash table
https://bugzilla.gnome.org/show_bug.cgi?id=766025
2016-05-15 12:31:33 +03:00
Sebastian Dröge
204a86af97 rtpsession: Don't notify about stats property changes while taking the session lock
The signal handlers might want to actually get the value of the stats
property, which would take the session lock again and deadlock.

This was introduced by 2e960e7075.

https://bugzilla.gnome.org/show_bug.cgi?id=766025
2016-05-11 09:28:13 +03:00
Miguel París Díaz
2e960e7075 rtpsession: Take session lock when creating stats
The access to the session hash table must happen while the session lock is
taken, otherwise another thread might modify the hash table while we're
creating the stats.

https://bugzilla.gnome.org/show_bug.cgi?id=766025
2016-05-06 09:24:22 +03:00
Stian Selnes
4c0e509328 rtpsession: Add new signal 'on-app-rtcp'
Similar to the 'on-feedback-rtcp' signal, but emitted for RTCP APP
packets.

https://bugzilla.gnome.org/show_bug.cgi?id=762217
2016-03-30 15:42:01 +03:00
Sebastian Dröge
b13b80ea39 rtpsession: Add a warning if an empty RTCP packet is tried to be sent
https://bugzilla.gnome.org/show_bug.cgi?id=759119
2015-12-07 14:41:51 +02:00
Alessandro Decina
dd4df554d5 rtpmanager: rtpsession: don't send empty RTCP packets
generate_rtcp can produce empty packets when reduced size RTCP is turned on.
Skip them since it doesn't make sense to push them and they cause errors with
elements that expect RTCP packets to contain data (like srtpenc).
2015-11-25 14:54:58 +11:00
Arun Raghavan
7e22ea5d5a rtpmanager: Document properties that are expressed in bits per second
This changed in 928cd110bc and
73c0c2920f but was not documented.

https://bugzilla.gnome.org/show_bug.cgi?id=747863
2015-11-05 09:48:59 +05:30
Arun Raghavan
e9692e4207 rtpmanager: Trivial gst-indent fixes 2015-11-05 09:48:59 +05:30
Stian Selnes
91a78053c7 rtpmanager: Add 'source-stats' to stats and notify
Add statitics from each rtp source to the rtp session property.
'source-stats' is a GValueArray where each element is a GstStructure of
stats for one rtp source.

The availability of new stats is signaled via g_object_notify.

https://bugzilla.gnome.org/show_bug.cgi?id=752669
2015-10-11 10:57:09 +01:00
Sebastian Dröge
f09da189aa rtpsession: Implement sending of reduced size RTCP packets
https://bugzilla.gnome.org/show_bug.cgi?id=750456
2015-10-11 10:47:47 +01:00
Miguel París Díaz
4c96094fbb rtpmanager: add "max-dropout-time" and "max-misorder-time" props
https://bugzilla.gnome.org/show_bug.cgi?id=751311
2015-10-07 12:06:47 +01:00
Hyunjun Ko
2b1f52755d rtpmanager: add new on-new-sender-ssrc, on-sender-ssrc-active signals
Allows for applications to get internal source's RTP statistics.
(eg. sender sources for a server/client)

https://bugzilla.gnome.org/show_bug.cgi?id=746747
2015-10-02 16:39:29 +03:00
Sebastian Dröge
dc059efa60 rtp: Use GST_BUFFER_PTS() instead of GST_BUFFER_TIMESTAMP()
The mix between all these in the RTP code is confusing, let's try to be
consistent.
2015-06-10 14:34:47 +02:00
Sebastian Dröge
b549ebd066 rtpsession: Override the SSRC from the packets' SSRC if none was given via caps or property 2015-06-07 10:33:27 +02:00
Sebastian Dröge
d650a310da rtpsession: Only suggest our internal ssrc if it's not a random one and was selected as internal ssrc
https://bugzilla.gnome.org/show_bug.cgi?id=749581
2015-06-05 16:45:54 +02:00
Jose Antonio Santos Cadenas
f8f23bbf5d rtpsession: Add support for receiving reduced size rtcp
See RFC 5506

https://bugzilla.gnome.org/show_bug.cgi?id=750332
2015-06-05 10:24:17 +02:00
Sebastian Dröge
647eefea67 rtpsession: Only schedule a timer when we actually have to send RTCP
Otherwise we will have 10s-100s of thread wakeups in feedback profiles, create
RTCP packets, etc. just to suppress them in 99% of the cases (i.e. if no
feedback is actually pending and no regular RTCP has to be sent).

This improves CPU usage and battery life quite a lot.

https://bugzilla.gnome.org/show_bug.cgi?id=746543
2015-06-02 11:38:15 +02:00
Sebastian Dröge
8ada98964d rtpsession: Remove useless goto
https://bugzilla.gnome.org/show_bug.cgi?id=746543
2015-06-02 11:38:15 +02:00
Sebastian Dröge
0f7e80ed59 rtpsession: Only put RRs and full SDES into regular RTCP packets
If we may suppress the packet due to the rules of RFC4585 (i.e. when
below the t-rr-int), we can send a smaller RTCP packet without RRs
and full SDES. In theory we could even send a minimal RTCP packet
according to RFC5506, but we don't support that yet.

https://bugzilla.gnome.org/show_bug.cgi?id=746543
2015-06-02 11:38:15 +02:00
Sebastian Dröge
6f830e5bd5 rtpsession: Keep track of tp/tn and t_rr_last separately
Otherwise we can't properly schedule RTCP in feedback profiles as we need to
distinguish the time when we last checked for sending RTCP (tp) but might have
suppressed it, and the time when we last actually sent a non-early RTCP
packet.

This together with the other changes should now properly implement RTCP
scheduling according to RFC4585, and especially allow us to send feedback
packets a lot if needed but only send regular RTCP packets every once in a
while.

https://bugzilla.gnome.org/show_bug.cgi?id=746543
2015-06-02 11:38:15 +02:00
Sebastian Dröge
3122ef4ae3 rtpsession: Add property for selecting RTP profile (AVP/AVPF/etc)
And modify our RTCP scheduling algorithm accordingly. We now can send more
RTCP packets if needed for feedback, but will throttle full RTCP packets by
rtcp-min-interval (t-rr-int from RFC4585).

In non-feedback mode, rtcp-min-interval is Tmin from RFC3550, which is
statically set to 1s or 0s by RFC4585. Tmin defines how often we should
send RTCP packets at most.

https://bugzilla.gnome.org/show_bug.cgi?id=746543
2015-06-02 11:38:15 +02:00
Sebastian Dröge
565cd49643 rtpsession: Don't crash if we receive FIR/PLI from a source we don't know 2015-05-21 13:26:53 +03:00
Santiago Carot-Nemesio
2fb1fe2ee3 rtpsession: Fix collection of statistics
Stats should be collected on the media rtp source not in the
sender one.

https://bugzilla.gnome.org/show_bug.cgi?id=749669
2015-05-21 12:56:12 +03:00
Sebastian Dröge
27729a2960 Revert "rtpsession: Also report internal sources in on-new-ssrc and on-ssrc-active"
This reverts commit d22ec49632.

Application code might expect that it only gets external sources on those
signals, and get confused by this. If anything we would need to add new
signals.
2015-05-07 14:51:45 +02:00
Sebastian Dröge
d22ec49632 rtpsession: Also report internal sources in on-new-ssrc and on-ssrc-active
Without this it seems impossible for an application to easily get notified
about the internal ssrcs that are created, e.g. sender sources, and also
to know when they are active and produce RTCP packets.

https://bugzilla.gnome.org/show_bug.cgi?id=746747
2015-05-06 11:21:22 +02:00
Sebastian Dröge
9d22ad421b rtpsession: The stats min_interval is in seconds, not nanoseconds
We have to scale it to compare it against our clock times.
2015-05-04 14:12:07 +02:00
Sebastian Dröge
afe1d5a89f rtpsession: Only return TRUE if early feedback was requested already and it's early enough 2015-05-04 14:11:00 +02:00
Sebastian Dröge
7596ed91b8 rtpsession: Use bandwidth calculation by default instead of some arbitrary hardcoded value
https://bugzilla.gnome.org/show_bug.cgi?id=747863
2015-04-27 16:45:25 +02:00
Sebastian Dröge
928cd110bc rtpsession: Bandwidth is supposed to be in bits/s, not bytes/s
https://bugzilla.gnome.org/show_bug.cgi?id=747863
2015-04-27 16:45:14 +02: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
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
bd19b08d6d rtpsession: Not sending early RTCP now because of dithering means we send it with the next compound packet 2015-04-14 18:42:44 +02:00
Sebastian Dröge
4223d0c114 rtpsession: Improve debug output a bit if we can't allow early feedback 2015-04-14 18:42:44 +02:00
Tim-Philipp Müller
c4fa54da17 Fix double semicolons 2015-03-10 09:31:20 +00:00
Santiago Carot-Nemesio
e05378ec16 rtp: Add Full Intra Request (FIR) packets to statistics
https://bugzilla.gnome.org/show_bug.cgi?id=745587
2015-03-04 12:04:40 +01:00
Santiago Carot-Nemesio
22791413f9 rtp: Add Packet Loss Indication (PLI) to statistics
This is helpful to provide statistics in the format defined in
http://w3c.github.io/webrtc-stats/#dictionary-rtcrtpstreamstats-members.

https://bugzilla.gnome.org/show_bug.cgi?id=745587
2015-03-04 12:04:07 +01:00
Sebastian Dröge
8984e18ef7 rtpsession: Add explanation why we have space for 32 hash tables
And also create only one, there's no need yet to create all 32 until
we implement RFC2762.
2015-03-04 11:30:43 +01:00
Sebastian Dröge
af2bdd6e15 Revert "rtpsession: Do not use an array of maps if they are not being used"
This reverts commit 1591adf4cd.

https://bugzilla.gnome.org/show_bug.cgi?id=745586#c1:
It's the beginning of an implementation of RFC 2762, which is needed for
large multicast groups. The implementation is not yet complete but why
not leave what is there and implement RFC 2762 instead?
2015-03-04 11:26:57 +01:00
Santiago Carot-Nemesio
1591adf4cd rtpsession: Do not use an array of maps if they are not being used
rtpsession declares an array of maps to store srrcs but only the
the key 0 is being used. This patch replaces the array of maps
for just one map and remove useless parameters in rtpsession

https://bugzilla.gnome.org/show_bug.cgi?id=745586
2015-03-04 11:25:30 +01:00
Sebastian Dröge
b79eff7f9b rtpsession: Handle first RTCP packet and early feedback correctly
According to RFC 4585 section 3.5.3 step 1 we are not allowed to send
an early RTCP packet for the very first one. It must be a regular one.

Also make sure to not use last_rtcp_send_time in any calculations until
we actually sent an RTCP packet already. In specific this means that we
must not use it for forward reconsideration of the current RTCP send time.
Instead we don't do any forward reconsideration for the first RTCP packet.
2015-02-11 10:32:46 +01:00
Sebastian Dröge
075eb10e65 rtpsession: Fix signal name
This wasn't meant to be pushed at all yet, but now that it's there
already it won't hurt to make it correct at least.
2015-01-30 18:22:31 +01:00
Sebastian Dröge
77511b156e rtpsession: Add new on-receiving-rtcp signal
This will be emitted whenever an RTCP packet is received. Different to
on-feedback-rtcp, this signal gets every complete RTCP packet and not
just the individual feedback packets.
2015-01-30 16:50:36 +01:00
Sebastian Dröge
e4ed852041 rtpsession: Deprecate rtcp-immediate-feedback-threshold property
It had no effect since quite some time and also is not needed in general,
especially not to switch between immediate feedback mode and early feedback
mode. The latest understanding of the RFC is that from the endpoint point of
view, both modes are exactly the same. RTCP is only allowed to use the
bandwidth as given by the RFC constraints, as such it is only ever possible
to schedule a RTCP packet early but it's against the RFC to schedule more RTCP
packets.

The difference between immediate feedback mode and early feedback mode is that
the former guarantees that an RTCP packet can be sent for every event
"immediately", which means that the bandwidth calculations from the RFC have
resulted in an RTCP scheduling interval that is small enough. Early feedback
mode on the other hand means that we can schedule some packets early to make
that happen, but it's not guaranteed at all that it's possible to schedule
an RTCP packet per event (i.e. they need to be accumulated or dropped).
2015-01-26 18:49:31 +01:00
Sebastian Dröge
b07b7736b3 rtpsession: Delay the next regular RTCP packet after early RTCP
This is required to not exceed the short term average RTCP bitrate when
using early feedback as compared to without early feedback.
2015-01-26 18:49:31 +01:00
Sebastian Dröge
bc9111a03d rtpsession: Add new send-rtcp-full signal
This indicates with a boolean return value if scheduling a new RTCP packet
within the requested delay was possible. Otherwise it behaves exactly like
send-rtcp. The only reason for adding a new signal is ABI compatibility.
2015-01-26 18:49:31 +01:00
Sebastian Dröge
60e2d0c84f rtpsession: Fix indention 2015-01-22 11:03:25 +01:00
Miguel París Díaz
e6504e3a65 rtpsession: fix Early Feedback Transmission
In early retransmission we are allowed to schedule 1 regular RTCP packet
at an earlier time. When we do that, we need to set allow_early to FALSE
and ignore/drop (or merge) all future requests for early transmission.
We now first check if we can schedule an early RTCP and if we can,
actually prepare the data for the next RTCP interval.

After we send the next regular RTCP after the early RTCP, we set
allow_early to TRUE again to allow more early requests.

Remove the condition for the immediate feedback for now.

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=738319
2014-10-22 13:13:47 +02:00