Commit graph

1218 commits

Author SHA1 Message Date
Tim-Philipp Müller
6cb51bd8cf rtpjitterbuffer: fix debug message on pt mismatch 2017-10-08 00:07:43 +01:00
Tim-Philipp Müller
d5f72418c8 rtpbin, rtspsrc: fix compiler warnings about 64-bit integer signednes
"warning: this decimal constant is unsigned only in ISO C90" with
gcc 4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.3)
2017-10-07 15:55:24 +01:00
Tim-Philipp Müller
a802f5df42 rtpjitterbuffer: implement basic chain_list function
Doesn't do anything fancy yet, but still avoids lots of
unnecessary locking/unlocking that would happen if the
default chain_list fallback function in GstPad got invoked.
2017-09-17 16:33:15 +01:00
Patrick Radizi
3de0244532 rtpbin: add option for sanity checking timestamp offset
Timestamp offsets needs to be checked to detect unrealistic values
caused for example by NTP clocks not in sync. The new parameter
max-ts-offset lets the user decide an upper offset limit. There
are two different cases for checking the offset based on if
ntp-sync is used or not:
1) ntp-sync enabled
   Only negative offsest are allowed since a positive offset would
   mean that the sender and receiver clocks are not in sync.
   Default vaule of max-ts-offset = 0 (disabled)
2) ntp-sync disabled
   Both positive and negative offsets are allowed.
   Default vaule of max-ts-offset = 3000000000
The reason for different default values is to be backwards
compatible.

https://bugzilla.gnome.org/show_bug.cgi?id=785733
2017-09-15 13:33:14 +03:00
Patrick Radizi
23f7739ba4 rtpbin: add option for increasing ts_offset gradually
Instant large changes to ts_offset may cause timestamps to move
backwards and also cause visible effects in media playback. The new
option max-ts-offset-adjustment lets the application control the rate to
apply changes to ts_offset.

https://bugzilla.gnome.org/show_bug.cgi?id=784002
2017-09-14 13:15:56 +03:00
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
Sebastian Dröge
71104f452e rtpbin: Also log local and SR RTP running times when doing ntp-sync=true 2017-08-29 19:14:25 +03:00
Matthew Waters
f602b8e5b0 rtpbin: also create session when creating the send_rtcp_src_%u pad
If one requests the send_rtcp_src_%u pad before a recv_rtcp_sink_%u pad,
the session/pad would never be created and NULL was returned.
Switching the request order would work.

https://bugzilla.gnome.org/show_bug.cgi?id=786718
2017-08-29 12:47:30 +10:00
Mathieu Duponchelle
5e48e85fb7 rtpstats: fix unsigned integer comparisons.
Callers of the API (rtpsource, rtpjitterbuffer) pass clock_rate
as a signed integer, and the comparison "<= 0" is used against
it, leading me to think the intention was to have the field
be typed as gint32, not guint32.

This led to situations where we could call scale_int with
a MAX_UINT32 (-1) guint32 as the denom, thus raising an
assertion.

https://bugzilla.gnome.org/show_bug.cgi?id=785991
2017-08-11 13:29:24 +02:00
Olivier Crête
96e71b0286 rtpsession: Send EOS if all internal sources sent bye
The ones which are not internal should not matter, and we should
wait for all sources to have sent their BYEs.

And add unit test

https://bugzilla.gnome.org/show_bug.cgi?id=773218
2017-07-04 21:14:10 -04:00
Olivier Crête
7e7e52caa0 rtpsession: Only send EOS if all sources have been marked bye
Now that multiple sender RTPSource can share the same RTPSession, we
must not send an EOS unless they're all marked bye.
2017-07-04 13:36:44 -04:00
Nicolas Dufresne
bf5cbce3b4 rtprtxreceive: Add memory and boudary checks
This element was not checking if mapping the RTP buffer and the payload
worked, and was not checking if the RTX payload was large enough.

https://bugzilla.gnome.org/show_bug.cgi?id=784484
2017-07-04 09:58:15 -04:00
Julien Isorce
afbabaefbe rtpstats: fix assertion 'denom > 0' failed
gst_util_uint64_scale_int takes a gint as denom parameter
whereas ctx->clock_rate is a guint32.

It happens when gst_rtp_packet_rate_ctx_reset set clock_rate
to -1.

So just define clock_rate as gint like it is done in rtpsource.h

https://bugzilla.gnome.org/show_bug.cgi?id=784250
2017-06-29 15:58:44 -04:00
Nicolas Dufresne
bbe0053f8a rtpjitterbuffer: Add a faststart-min-packets property
When set this property will allow the jitterbuffer to start delivering
packets as soon as N most recent packets have consecutive seqnum. A
faststart-min-packets of zero disables this feature. This heuristic is
also used in rtpsource which implements the probation mechanism and a
similar heuristic is used to handle long gaps.

https://bugzilla.gnome.org/show_bug.cgi?id=769536
2017-06-28 11:51:10 -04:00
Juan Navarro
72d2afda18 rtpsession: print value of unknown RTCP Payload Type
This adds printing the actual value of any unknown RTCP PT
to the already existing WARNING log message.

https://bugzilla.gnome.org/show_bug.cgi?id=783248
2017-05-31 10:20:27 +03:00
Nicolas Dufresne
b68d936ae0 Remove plugin specific static build option
Static and dynamic plugins now have the same interface. The standard
--enable-static/--enable-shared toggle are sufficient.
2017-05-16 14:41:19 -04:00
Tim-Philipp Müller
50a4b5bc0d Revert "rtpbin: pipeline gets an EOS when any rtpsources byes"
This reverts commit eeea2a7fe8.

It breaks EOS in some sender pipelines, see
https://bugzilla.gnome.org/show_bug.cgi?id=773218#c20
2017-04-19 12:28:12 +01:00
George Kiagiadakis
7f6c783930 rtprtxqueue: implement handling of the max-size-time property
https://bugzilla.gnome.org/show_bug.cgi?id=780867
2017-04-11 09:44:33 +03:00
George Kiagiadakis
501bf0e8d1 rtpmux: fix output segment and buffer DTS to correspond to the flattened PTS
https://bugzilla.gnome.org/show_bug.cgi?id=780347
2017-03-24 11:09:46 +02:00
George Kiagiadakis
3e91601fbb rtprtxqueue: add basic documentation and example pipelines
Mostly explaining the difference between rtprtxqueue and rtprtxsend.
2017-03-20 12:10:55 +02:00
George Kiagiadakis
ba606b96d3 rtprtxreceive: fix example pipelines and improve the documentation
https://bugzilla.gnome.org/show_bug.cgi?id=771383
2017-03-17 19:07:34 +02:00
George Kiagiadakis
0e65304d5c rtpsession: print the correct variable in debug statement
This debug statement is meant to print the time since the last (early)
RTCP transmission, not the last regular RTCP transmission (which also
happens to be set a few lines above to current_time, so the debug output
is just confusing)
2017-03-16 17:46:46 +02: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
Miguel París Díaz
9ffef7ecd5 rtpsource: fix warning message
https://bugzilla.gnome.org/show_bug.cgi?id=780105
2017-03-16 16:33:02 +02:00
Miguel París Díaz
54a2f33e47 rtpsource: get clock-rate from pt if needed to generate SR
https://bugzilla.gnome.org/show_bug.cgi?id=780105
2017-03-16 15:48:37 +02:00
George Kiagiadakis
71b63d54fe rtprtxreceive: fix potential leak of old, unassociated, association requests
https://bugzilla.gnome.org/show_bug.cgi?id=722560
2017-03-01 10:50:43 +02:00
Andrew
76792a5c20 rtpjitterbuffer: Don't always reset PTS to 0 after a gap
In function rtp_jitter_buffer_calculate_pts: If gap in incoming RTP
timestamps is more than (3 * jbuf->clock_rate) we call
rtp_jitter_buffer_reset_skew which resets pts to 0. So components down
the pipeline (playes, mixers) just skip frames/samples until pts becomes
equal to pts before gap.

In version 1.10.2 and before this checking was bypassed for packets with
"estimated dts", and gaps were handled correctly.

https://bugzilla.gnome.org/show_bug.cgi?id=778341
2017-02-26 12:41:19 +02:00
Miguel París Díaz
3aa69ca0bb rtpsession: relate received FIRs and PLIs to source
This is needed in order to:
 - Avoid ignoring requests for different media sources.
 - Add SSRC field in the GstForceKeyUnit event.

https://bugzilla.gnome.org/show_bug.cgi?id=778013
2017-02-02 12:13:59 -05:00
Santiago Carot-Nemesio
a1e4249131 rtpstats: Keep number of nacks sent/received per source
Currently, the nack packets sent or received are kept at session level,
which makes it impossible to distinguish how many of these packages were
sent/received per ssrc when several sources are in the same session. This
patch is aligned with the https://www.w3.org/TR/webrtc-stats/#dom-rtcrtpstreamstats

https://bugzilla.gnome.org/show_bug.cgi?id=776714
2017-01-24 12:38:50 +02:00
Mathieu Duponchelle
191330cba8 rtxqueue: Expose basic statistics as properties.
Statistics about the total number of retransmission requests
and the actual number of retransmitted packets can be helpful
at application-level.

https://bugzilla.gnome.org/show_bug.cgi?id=777182
2017-01-12 19:49:30 +01:00
Tim-Philipp Müller
d7b2820b73 Fix indentation 2017-01-09 19:05:10 +00:00
Reynaldo H. Verdejo Pinochet
264be35e3c rtpmanager: place content before Since-version API marker
Avoids confusing the parser
2016-12-14 14:38:38 -08:00
Edward Hervey
e5158ca496 jitterbuffer: Don't leak duplicate items
When providing items with a seqnum, there is a (very small) probability
that an element with the same seqnum already exists. Don't forget
to free that item if it wasn't inserted.

And avoid returning undefined values when dealing with duplicate items
2016-12-02 09:01:57 +01: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
Sebastian Dröge
34db78b645 rtpbin: Handle create_session() returning NULL in bundle code
CID 1394492.
2016-11-23 18:34:04 +02:00
Sebastian Dröge
15630db146 rtpmux: Mark pad as needing reconfiguration again if it failed
And return FLUSHING instead of NOT_NEGOTIATED on flushing pads.

https://bugzilla.gnome.org/show_bug.cgi?id=774623
2016-11-18 12:04:45 +02:00
Philippe Normand
dcd3ce9751 rtpbin: receive bundle support
A new signal named on-bundled-ssrc is provided and can be
used by the application to redirect a stream to a different
GstRtpSession or to keep the RTX stream grouped within the
GstRtpSession of the same media type.

https://bugzilla.gnome.org/show_bug.cgi?id=772740
2016-11-16 08:56:34 +01:00
Havard Graff
1a4393fb4d rtpjitterbuffer: fix timer-reuse bug
When doing rtx, the jitterbuffer will always add an rtx-timer for the next
sequence number.

In the case of the packet corresponding to that sequence number arriving,
that same timer will be reused, and simply moved on to wait for the
following sequence number etc.

Once an rtx-timer expires (after all retries), it will be rescheduled as
a lost-timer instead for the same sequence number.

Now, if this particular sequence-number now arrives (after the timer has
become a lost-timer), the reuse mechanism *should* now set a new
rtx-timer for the next sequence number, but the bug is that it does
not change the timer-type, and hence schedules a lost-timer for that
following sequence number, with the result that you will have a very
early lost-event for a packet that might still arrive, and you will
never be able to send any rtx for this packet.

Found by Erlend Graff - erlend@pexip.com

https://bugzilla.gnome.org/show_bug.cgi?id=773891
2016-11-04 16:56:56 +02:00
Havard Graff
fb9c75db36 rtpjitterbuffer: fix lost-event using dts instead of pts
The lost-event was using a different time-domain (dts) than the outgoing
buffers (pts). Given certain network-conditions these two would become
sufficiently different and the lost-event contained timestamp/duration
that was really wrong. As an example GstAudioDecoder could produce
a stream that jumps back and forth in time after receiving a lost-event.

The previous behavior calculated the pts (based on the rtptime) inside the
rtp_jitter_buffer_insert function, but now this functionality has been
refactored into a new function rtp_jitter_buffer_calculate_pts that is
called much earlier in the _chain function to make pts available to
various calculations that wrongly used dts previously
(like the lost-event).

There are however two calculations where using dts is the right thing to
do: calculating the receive-jitter and the rtx-round-trip-time, where the
arrival time of the buffer from the network is the right metric
(and is what dts in fact is today).

The patch also adds two tests regarding B-frames or the
“rtptime-going-backwards”-scenario, as there were some concerns that this
patch might break this behavior (which the tests shows it does not).
2016-11-04 16:51:20 +02:00
Havard Graff
bea35f97c8 rtpjitterbuffer: fix bug in reschedule_timer
The new timeout is always going to be (timeout + delay), however, the
old behavior compared the current timeout to just (timeout), basically
being (delay) off.

This would happen if rtx-delay == rtx-retry-timeout, with the result that
a second rtx attempt for any buffers would be scheduled immediately instead
of after rtx-delay ms.

Simply calculate (new_timeout = timeout + delay) and then use that instead.

https://bugzilla.gnome.org/show_bug.cgi?id=773905
2016-11-04 16:40:14 +02:00
Alejandro G. Castro
6e7816c589 rtpbin: avoid generating errors when rtcp messages are empty and check the queue is not empty
Add a check to verify all the output buffers were empty for the
session in a timout and log an error.

https://bugzilla.gnome.org/show_bug.cgi?id=773269
2016-11-01 20:17:20 +02:00
Alejandro G. Castro
eeea2a7fe8 rtpbin: pipeline gets an EOS when any rtpsources byes
Instead of sending EOS when a source byes we have to wait for
all the sources to be gone, which means they already sent BYE and
were removed from the session. We now handle the EOS in the rtcp
loop checking the amount of sources in the session.

https://bugzilla.gnome.org/show_bug.cgi?id=773218
2016-11-01 20:16:18 +02:00
Tim-Philipp Müller
cae9ec0ad8 ext, gst: fix indentation 2016-09-15 09:53:07 +01:00
Thomas Bluemel
567afdd4d3 rtpjitterbuffer: Fix calculating next_seqnum when dropping old buffers from a full queue.
Fixes calculating the next sequence number when a ITEM_TYPE_LOST with more than one
definitely lost packets is encountered.

https://bugzilla.gnome.org/show_bug.cgi?id=769757
2016-09-14 19:47:28 -04:00
Havard Graff
f440b074b1 rtpjitterbuffer: improved rtx-rtt averaging
The basic idea is this:
1. For *larger* rtx-rtt, weigh a new measurement as before
2. For *smaller* rtx-rtt, be a bit more conservative and weigh a bit less
3. For very large measurements, consider them "outliers"
   and count them a lot less

The idea being that reducing the rtx-rtt is much more harmful then
increasing it, since we don't want to be underestimating the rtt of the
network, and when using this number to estimate the latency you need for
you jitterbuffer, you would rather want it to be a bit larger then a bit
smaller, potentially losing rtx-packets. The "outlier-detector" is there
to prevent a single skewed measurement to affect the outcome too much.
On wireless networks, these are surprisingly common.

https://bugzilla.gnome.org/show_bug.cgi?id=769768
2016-09-14 19:37:50 -04:00
Stian Selnes
f8238f0a9f rtpjitterbuffer: Detect whether to assume equidistant spacing when loss
Assuming equidistant packet spacing when that's not true leads to more
loss than necessary in the case of reordering and jitter. Typically this
is true for video where one frame often consists of multiple packets
with the same rtp timestamp. In this case it's better to assume that the
missing packets have the same timestamp as the last received packet, so
that the scheduled lost timer does not time out too early causing the
packets to be considered lost even though they may arrive in time.

https://bugzilla.gnome.org/show_bug.cgi?id=769768
2016-09-14 19:37:50 -04:00
Stian Selnes
2eb7383816 rtpjitterbuffer: Don't request rtx if 'now' is past retry period
There is no need to schedule another EXPECTED timer if we're already
past the retry period. Under normal operation this won't happen, but if
there are more timers than the jitterbuffer is able to process in
real-time, scheduling more timers will just make the situation worse.
Instead, consider this packet as lost and move on. This scenario can
occur with high loss rate, low rtt and high configured latency.

https://bugzilla.gnome.org/show_bug.cgi?id=769768
2016-09-14 19:37:50 -04:00
Stian Selnes
ab49dfd0b2 rtpjitterbuffer: Fix lost duration when gap after lost timer
This patch fixes an issue with the estimated gap duration when there is
a gap immediately after a lost timer has been processed. Previously
there was a discrepancy beteen the gap in seqnum and gap in dts which
would cause wrong calculated duration. The issue would only be seen with
retranmission enabled since when it's disabled lost timers are only
created when a packet is received and the actual gap length and last dts
is known.

https://bugzilla.gnome.org/show_bug.cgi?id=769768
2016-09-14 19:37:50 -04:00
Havard Graff
dd020f5cc8 rtpjitterbuffer: Expose rtx-deadline as a property
The default -1 gives the old behavior.

https://bugzilla.gnome.org/show_bug.cgi?id=769768
2016-09-14 19:37:50 -04:00
Havard Graff
8087a8a31c rtpjitterbuffer: Improved expected-timer handling when gap > 0
https://bugzilla.gnome.org/show_bug.cgi?id=769768
2016-09-14 19:37:50 -04:00