Commit graph

1279 commits

Author SHA1 Message Date
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
Stian Selnes
38a7545003 rtpjitterbuffer: Major improvements for RTX stats
Stats should also be collected for unsuccessful packets.

rtx-rtt is very important for determining the necessary configured
latency on the jitterbuffer. It's especially important to be able to
increase the latency when retransmitted packets arrive too late and are
considered lost. This patch includes these late packets in the
calculation of the various rtx stats, making them more correct and
useful.

Also in the case where the original packet arrives after a NACK is sent,
the received RTX packet should update the stats since it provides useful
information about RTT.

The RTT is only updated if and only if all requested retranmissions are
received. That way the RTT is guaranteed to make sense. If not we don't
know which request the packet is a response to and the RTT may be bogus.
A consequence of this patch is that RTT is not updated for a request
when one of the RTX packets for that seqnum is lost, but that since
measured RTT will be more accurate.

The implementation store the RTX information from the timed out timers
and use this when the retransmitted packet arrives. For performance
these timers are stored separately from the "normal" timers in order to
not impact performance (see attached performance test).

https://bugzilla.gnome.org/show_bug.cgi?id=769768
2016-09-14 19:37:50 -04:00
Havard Graff
1b868cc9b1 rtpjitterbuffer: Add and expose more stats and increase testing of it
Add num-pushed and num-lost.
Expose num-late, num-duplicates and avg-jitter.

https://bugzilla.gnome.org/show_bug.cgi?id=769768
2016-09-14 19:37:50 -04:00
Stian Selnes
531199d5c4 rtxreceive: Set buffer flag for retransmitted packets
https://bugzilla.gnome.org/show_bug.cgi?id=769768
2016-09-14 19:37:50 -04:00
Havard Graff
1436fc01e9 rtpjitterbuffer: Option to disable rtx-delay-reorder
When disabled we can save some iterations over timers.

There is probably an argument for rtx-delay-reorder to exist, but
for normal operations, handling jitter (reordering) is something a
jitterbuffer should do, and this variable feels like functionality that
is not "in-sync" with what the jitterbuffer is trying to achieve.

Example: You have 50ms jitter on your network, and are receiving
audio packets with 10ms durations. An audio packet should not be
considered late until its rtx-timeout has expired (and hence a rtx-event
is sent), but with rtx-delay-reorder, events will be sent pretty much
all the time due to the jitter on the network.

Point being: The jitterbuffer should adapt its size to the measured network
jitter, and then rtx-delay-reorder needs to adapt as well, or simply
get out of the way and let the other (better) rtx-mechanisms do their job.

Also change find_timer to only use seqnum as an argument, since there
will only ever be one timer per seqnum at any given time. In the
one case where the type matters, the caller simply checks the type.

https://bugzilla.gnome.org/show_bug.cgi?id=769768
2016-09-14 19:37:50 -04:00
Olivier Crête
4fceb5050f Revert "rtpmux: fix PROP_TIMESTAMP_OFFSET range problems"
This broke API, so we need a better solution!

This reverts commit c7579d31a6.
2016-08-26 12:06:51 -04:00
Havard Graff
c7579d31a6 rtpmux: fix PROP_TIMESTAMP_OFFSET range problems
It could not set the offset for the full guint32 range.
2016-08-26 11:57:14 -04:00
Havard Graff
7ad7266163 rtpbin: introduce max-streams property
To be able to cap the number of allowed streams for one session.

This is useful for preventing DoS attacks, where a sender can change
SSRC for every buffer, effectively bringing rtpbin to a halt.

https://bugzilla.gnome.org/show_bug.cgi?id=770292
2016-08-26 11:57:06 -04:00
Havard Graff
b33470f80c rtpsource: reordered packets are very normal, and should not be a warning 2016-08-26 11:53:22 -04:00
Havard Graff
babc591707 rtpsession: degrade g_warning to GST_ERROR
So we don't blow up while investigating
2016-08-26 11:53:22 -04:00
Stian Selnes
61bc228a71 rtpsession: sanity check RTT before ignoring PLI/FIR 2016-08-25 18:28:44 -04:00
Stian Selnes
85a56f8ee3 rtpsession: handle sdes messages with non-utf8 more gracefully 2016-08-25 18:28:44 -04:00
Havard Graff
1ef896b29d gstrtpsession: refactor duplicate code into a function
Less code, easier to read, more consistent.

https://bugzilla.gnome.org/show_bug.cgi?id=770293
2016-08-23 15:09:03 -04:00
Vincent Penquerc'h
0fb0c0c8e6 rtpbin: fix typo in max-misorder-time property name 2016-08-23 17:19:17 +01:00
Nirbheek Chauhan
b09f478e80 Add support for Meson as alternative/parallel build system
https://github.com/mesonbuild/meson

With contributions from:

Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)

Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded

... and many more. For more details see:

http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.html
http://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html

Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
2016-08-20 11:21:12 +01:00
Thomas Bluemel
4dff74358e rtpjitterbuffer: Actually calculate the packet rate for max-dropout and max-misorder calculations.
https://bugzilla.gnome.org/show_bug.cgi?id=751311
2016-08-10 19:49:27 +02:00
Thomas Bluemel
e7d4ad7ac7 rtpjitterbuffer: Don't warn for duplicate packets
This is a normal scenario and should not be a warning.  This can
happen frequently when re-transmits of lost packets are enabled.

https://bugzilla.gnome.org/show_bug.cgi?id=762208
2016-08-10 19:39:42 +02:00
Thiago Santos
7f0381fdd9 rtpjitterbuffer: avoid unref of null buffer
The current 'l' pointer will be NULL when the loop
is interrupted with a 'break' statement. Need to have
it advance to the next list item before interrupting.
2016-08-04 00:36:28 -03:00
Aurélien Zanelli
f8f8935c77 rtpjitterbuffer: fix RTPJitterBufferMode documentation
Documentation lacks '@' before each enum values and there was an extra
line after symbol section which confuses GTK-Doc parser.

https://bugzilla.gnome.org/show_bug.cgi?id=767788
2016-06-17 15:16:45 +03: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
Olivier Crête
5328378132 rtpjitterbuffer: Work with non-TIME segments
With non-time segments, it now assumes that the arrival time of packets
is not relevant and that only the RTP timestamp matter and it produces
an output segment start at running time 0.

https://bugzilla.gnome.org/show_bug.cgi?id=766438
2016-06-08 14:49:49 -04:00
Miguel París Díaz
389e0abeb0 rtpsource: complete warn log with SSRC
https://bugzilla.gnome.org/show_bug.cgi?id=767195
2016-06-06 10:47:17 +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
Olivier Crête
0ebdb97797 jitterbuffer: Upgrade debug message to error
It causes the entire pipeline to fail, it should be easier to find.
2016-05-14 12:36:08 +02: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
Havard Graff
8f7962e1c3 rtpjitterbuffer: Fix stall when receiving already lost packet
When a packet arrives that has already been considered lost as part of a
large gap the "lost timer" for this will be cancelled. If the remaining
packets of this large gap never arrives, there will be missing entries
in the queue and the loop function will keep waiting for these packets
to arrive and never push another packet, effectively stalling the
pipeline.

The proposed fix conciders parts of a large gap definitely lost (since
they are calculated from latency) and ignores the late arrivals.

In practice the issue is rare since large gaps are scheduled immediately,
and for the stall to happen the late arrival needs to be processed
before this times out.

https://bugzilla.gnome.org/show_bug.cgi?id=765933
2016-05-06 14:32:42 +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
Sebastian Dröge
608b4ee53c rtpjitterbuffer: Ensure to not take caps with the wrong pt for getting the clock-rate
Especially the caps on the pad might be out of date, and the new caps would be
provided for the current pt via the request-pt-map signal.

https://bugzilla.gnome.org/show_bug.cgi?id=765689
2016-04-27 20:52:27 +03:00
Jan Schmidt
a660ac7e88 rtpjitterbuffer: Fix debug output when resyncing
Don't output the pointer value of the time() function as a timestamp
by using the correct variable.

Fixes build on Raspberry Pi 3.
2016-04-15 14:35:07 +00:00
Paolo Pettinato
40fbffc208 rtpmux: Forward sticky events on buffer lists too, not only on buffers
https://bugzilla.gnome.org/show_bug.cgi?id=764933
2016-04-12 15:22:14 +03:00
Sebastian Dröge
4a0de53cc1 rtpjitterbuffer: Fix rtp_jitter_buffer_get_ts_diff() fill level calculation
The head of the queue is the oldest packet (as in lowest seqnum), the tail is
the newest packet. To calculate the fill level, we should calculate tail-head
while considering wraparounds. Not the other way around.

Other code is already doing this in the correct order.

https://bugzilla.gnome.org/show_bug.cgi?id=764889
2016-04-12 10:17:57 +03:00
Sebastian Dröge
95dc198563 rtpmanager: It's GST_LIBS, not GST_LIBS_LIBS 2016-04-11 10:44:56 +03:00
Edward Hervey
5fa1c2ba59 jiterbuffer: Move assertion to the right location
We shouldn't have "late" lost timers at that point
2016-04-07 13:01:52 +02:00
Edward Hervey
b82da62922 jitterbuffer: Speed up lost timeout handling
When downstream blocks, "lost" timers are created to notify the
outgoing thread that packets are lost.

The problem is that for high packet-rate streams, we might end up with
a big list of lost timeouts (had a use-case with ~1000...).

The problem isn't so much the amount of lost timeouts to handle, but
rather the way they were handled. All timers would first be iterated,
then the one selected would be handled ... to re-iterate the list again.

All of this is being done while the jbuf lock is taken, which in some use-cases
would return in holding that lock for 10s... blocking any buffers from
being accepted in input... which would then arrive late ... which would
create plenty of lost timers ... which would cause the same issue.

In order to avoid that situation, handle the lost timers immediately when
iterating the list of pending timers. This modifies the complexity from
a quadratic to a linear complexity.

https://bugzilla.gnome.org/show_bug.cgi?id=762988
2016-04-07 10:14:24 +02:00
Edward Hervey
d656fe8d54 jitterbuffer: Don't create lost events if we don't need them
When "do-lost" is set to FALSE we don't use/send the lost events.
In that case, don't create them to start with :)

https://bugzilla.gnome.org/show_bug.cgi?id=762988
2016-04-07 10:13:56 +02:00
Edward Hervey
cf866a8469 jitterbuffer: Add tracing of lock usage
Helps with debugging lock usage

https://bugzilla.gnome.org/show_bug.cgi?id=762988
2016-04-07 10:06:18 +02:00
Sebastian Dröge
df247f091c rtpjitterbuffer: Add RFC7273 media clock handling
https://bugzilla.gnome.org/show_bug.cgi?id=762259
2016-04-03 11:24:34 +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
Minjae Kim
eb13a1d607 rtpmanager: Set to initial value for 'ntpns' in get_current_times()
Initialize "ntpns" variable to -1 as the OE compiler for some reason doesn't
realize that the variable is set in all code paths.

https://bugzilla.gnome.org/show_bug.cgi?id=764119
2016-03-29 10:21:07 +03: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
Nirbheek Chauhan
78847d03cf rtpmanager: Some comment and documentation clarifications/fixes 2016-03-15 09:32:47 +00:00
Sebastian Dröge
b6e10be278 Revert "rtpjitterbuffer: don't forget to unlock mutex in error code path in two cases"
This reverts commit a7fb7b5359.

The mutex is taken by the caller, we should keep it locked when returning so
the caller can unlock it again.
2016-03-02 13:13:24 +02:00
Tim-Philipp Müller
a7fb7b5359 rtpjitterbuffer: don't forget to unlock mutex in error code path in two cases 2016-03-01 14:14:36 +00:00
Stian Selnes
5a2cc41398 rtpmanager: Don't warn for duplicate/reordered packets
This is a normal scenario and should not be a warning.

https://bugzilla.gnome.org/show_bug.cgi?id=762208
2016-02-21 22:37:57 +00:00
Miguel París Díaz
92affe2dec rtpbin: add "get-session" signal
This gets the GstRTPSession element, as compared to the RTPSession object
that is returned by get-internal-session.

https://bugzilla.gnome.org/show_bug.cgi?id=759293
2016-02-16 13:39:52 +02:00
Sebastian Dröge
366bbffcd8 Revert "WIP: rtpjitterbuffer: Add RFC7273 media clock handling"
This reverts commit 271501f657.

It wasn't meant to be pushed yet as the commit message indicates.
2016-01-18 11:30:45 +02:00
Sebastian Dröge
271501f657 WIP: rtpjitterbuffer: Add RFC7273 media clock handling 2016-01-18 08:58:59 +02:00
Sebastian Dröge
e4b2360e6e rtpjitterbuffer: Fix packet dropping after a big discont
We would queue 5 consective packets before considering a reset and a proper
discont here. Instead of expecting the next output packet to have the current
seqnum (i.e. the fifth), expect it to have the first seqnum. Otherwise we're
going to drop all queued up packets.
2015-12-09 12:24:09 +02: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
Luis de Bethencourt
9fee2c7c9f rtpmanager: switch G_GINT64_FORMAT for GST_STIME_ARGS
No need to use G_GINT64_FORMAT for potentially negative values of
GstClockTimeDiff. Since 1.6 these can be handled with GST_STIME_ARGS.
Plus it creates more readable values in the logs.

https://bugzilla.gnome.org/show_bug.cgi?id=757480
2015-11-03 14:47:00 +00:00
Luis de Bethencourt
d4f094f587 rtpmanager: use GST_STIME_ARGS for GstClockTimeDiff
No need to manually handle negative values of diff, GST_STIME_ARGS does
exactly this.
2015-11-03 14:26:32 +00:00
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
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
Sebastian Dröge
2be5416e4a rtpbin: Add missing break 2015-10-07 23:23:45 +01:00
Miguel París Díaz
f321bfeaf4 rtpmanager: Take into account packet rate for max-dropout and max-misorder calculations
https://bugzilla.gnome.org/show_bug.cgi?id=751311
2015-10-07 12:07:18 +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
Olivier Crête
58073eaa7a rtpmux: Use default upstream event handling
https://bugzilla.gnome.org/show_bug.cgi?id=752694
2015-10-02 17:39:10 -04:00
Olivier Crête
43c213fc5d rtpmux: As 0xFFFFFFFF is a valid ssrc, check if it has been set
https://bugzilla.gnome.org/show_bug.cgi?id=752694
2015-10-02 17:39:10 -04:00
Havard Graff
d5e26ab909 gstrtpmux: allow the ssrc-property to decide ssrc on outgoing buffers
By not doing this, the muxer is not effectively a rtpmuxer, rather a
funnel, since it should be a single stream that exists the muxer.

If not specified, take the first ssrc seen on a sinkpad, allowing upstream
to decide ssrc in "passthrough" with only one sinkpad.

Also, let downstream ssrc overrule internal configured one

We hence has the following order for determining the ssrc used by
rtpmux:

0. Suggestion from GstRTPCollision event
1. Downstream caps
2. ssrc-Property
3. (First) upstream caps containing ssrc
4. Randomly generated

https://bugzilla.gnome.org/show_bug.cgi?id=752694
2015-10-02 17:39:06 -04:00
Miguel París Díaz
bf0e4f65b4 rtpstats: add utility for calculating RTP packet rate 2015-10-02 19:25:27 +01:00
Hyunjun Ko
b814d7ed25 rtpsource: doesn't handle probation and rtp gap in case of sender
https://bugzilla.gnome.org/show_bug.cgi?id=754548
2015-10-02 16:42:36 +03: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
Jan Schmidt
866c86dd37 Fix some compiler warnings when building with G_DISABLE_ASSERT
Touches rtpmanager and gdkpixbufsink
2015-09-26 22:18:26 +10:00
Sebastian Dröge
7046852e7d gst: Don't use deprecated gst_segment_to_position() 2015-09-26 00:12:46 +02:00
Sebastian Dröge
01c0f8723f rtpbin/rtpjitterbuffer/rtspsrc: Add property to set maximum ms between RTCP SR RTP time and last observed RTP time
https://bugzilla.gnome.org/show_bug.cgi?id=755125
2015-09-25 23:55:05 +02:00
Sebastian Dröge
a0ae6b5b5a rtpbin/session: Allow RTCP sync to happen based on capture time or send time
Send time is the previous behaviour and the default, but there are use cases
where you want to synchronize based on the capture time.

https://bugzilla.gnome.org/show_bug.cgi?id=755125
2015-09-25 23:55:00 +02:00
Mark Nauwelaerts
b7b244f356 rtpjitterbuffer: reset just a bit more upon flush_stop 2015-09-13 15:42:06 +02:00
Mark Nauwelaerts
1e7a3473fd rtpjitterbuffer: remove dead struct member 2015-09-13 15:41:03 +02:00
Sebastian Dröge
68a9209408 rtpjitterbuffer: Keep the DTS estimate if we got no DTS after a jitterbuffer reset
Otherwise we will just output buffers without timestamps after a reset if no
timestamps are provided by upstream, e.g. when using RTSP over TCP.

https://bugzilla.gnome.org/show_bug.cgi?id=749536
2015-08-13 16:45:16 +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
Havard Graff
764bbf99a8 rtpmux: handle different ssrc's on sinkpads
Do this by not putting the ssrc from the src pads in the caps used to
probe other sinkpads, and then  intersecting with it later.

https://bugzilla.gnome.org/show_bug.cgi?id=752491
2015-07-16 16:46:11 -04:00
Sebastian Dröge
582ade2c42 rtpjitterbuffer: Fix indention 2015-07-10 00:13:32 +03:00
Sebastian Dröge
ae8acc0973 rtpjitterbuffer: Always estimate DTS from the current clock time
Estimating it from the RTP time will give us the PTS, so in cases of PTS!=DTS
we would produce wrong DTS. As now the estimated DTS is based on the clock,
don't store it in the jitterbuffer items as it would otherwise be used in the
skew calculations and would influence the results. We only really need the DTS
for timer calculations.

https://bugzilla.gnome.org/show_bug.cgi?id=749536
2015-07-10 00:13:22 +03:00
Sebastian Dröge
6e7c724afa rtpjitterbuffer: Calculate DTS from the clock if we had none for the first packet after a reset
https://bugzilla.gnome.org/show_bug.cgi?id=749536
2015-07-08 23:19:52 +03:00
Havard Graff
ddd032f56b rtpjitterbuffer: fix gap-time calculation and remove "late"
The amount of time that is completely expired and not worth waiting for,
is the duration of the packets in the gap (gap * duration) - the
latency (size) of the jitterbuffer (priv->latency_ns). This is the duration
that we make a "multi-lost" packet for.

The "late" concept made some sense in 0.10 as it reflected that a buffer
coming in had not been waited for at all, but had a timestamp that was
outside the jitterbuffer to wait for. With the rewrite of the waiting
(timeout) mechanism in 1.0, this no longer makes any sense, and the
variable no longer reflects anything meaningful (num > 0 is useless,
the duration is what matters)

Fixed up the tests that had been slightly modified in 1.0 to allow faulty
behavior to sneak in, and port some of them to use GstHarness.

https://bugzilla.gnome.org/show_bug.cgi?id=738363
2015-07-08 23:18:48 +03:00
Stian Selnes
40524e5a49 Revert "rtpjitterbuffer: Fix expected_dts calc in calculate_expected"
This reverts commit 05bd708fc5.

The reverted patch is wrong and introduces a regression because there
may still be time to receive some of the packets included in the gap
if they are reordered.
2015-07-08 23:18:48 +03:00
Sebastian Dröge
4e23481d9f rtpjitterbuffer: Calculate receive time if we don't have any
This is required to properly schedule packet loss timers and make
sure all our calculations work properly.

https://bugzilla.gnome.org/show_bug.cgi?id=749536
2015-07-08 17:02:05 +03:00
Sebastian Dröge
243730ced4 rtpjitterbuffer: Handle seqnum gaps in TCP streams without erroring out or overflowing calculations
That is, handle DTS==GST_CLOCK_TIME_NONE correctly.

https://bugzilla.gnome.org/show_bug.cgi?id=749536
2015-07-08 15:15:00 +03:00
Stefan Sauer
12930c2f8c docs: fix "Symbol name not found at the start of the comment block"
Add symbols or change comment into a regular comment.
2015-07-07 17:12:02 +02:00
Miguel París Díaz
5ae672fd22 rtpjitterbuffer: Consider timers len to compare with RTP_MAX_DROPOUT
When there are a lot of small gaps, we can consider that there is
a big gap (too losses) to reset the buffer.

https://bugzilla.gnome.org/show_bug.cgi?id=751636
2015-07-02 18:38:46 +02:00
Sebastian Dröge
3df0cce65d rtpjitterbuffer: If possible, always update the current time before looping over all timers
If we have a clock, update "now" now with the very latest running time we have.
If timers are unscheduled below we otherwise wouldn't update now (it's only updated
when timers expire), and also for the very first loop iteration now would otherwise
always be 0.

Also the time is used for the timeout functions, e.g. to calculate any times
for the next timeouts and we would otherwise pass too old times there.

https://bugzilla.gnome.org/show_bug.cgi?id=751636
2015-07-02 16:45:59 +02:00
Miguel París Díaz
2176f31174 rtpjitterbuffer: refactor handle_next_buffer
The goal of this patch is making handle_next_buffer function
more readable avoiding unnecesary gotos and adding other
cosmetic changes.
2015-07-01 16:06:40 +02:00
Sebastian Dröge
de5cd0995b Revert "rtpjitterbuffer: If we have an immediate timeout, don't try to find an earlier timeout"
This reverts commit 0c21cd7177.

If we have multiple immediate timers, we want to first handle the one with the
lowest sequence number... which would be broken now.

Instead of this we should just use a GSequence for the timers, and have them
sorted first by timestamp, and for equal timestamps by sequence number. Then
we would always only have to take the very first timer from the list and never
have to look at any others.
2015-06-29 10:36:58 +02:00
Sebastian Dröge
0c21cd7177 rtpjitterbuffer: If we have an immediate timeout, don't try to find an earlier timeout
If we have lots of such immediate timeouts, we would otherwise have quadratic
runtime in the number of timeouts.
2015-06-29 10:14:05 +02:00
Hyunjun Ko
a1bff413a1 rtpbin/session: fix description
https://bugzilla.gnome.org/show_bug.cgi?id=751496
2015-06-25 16:31:51 +02:00
Sangkyu Park
2663388000 rtpjitterbuffer: Minor clean-up
1. Fix the code which is wrong coding style.
2. Fix a typing error of comment.

https://bugzilla.gnome.org/show_bug.cgi?id=751316
2015-06-22 13:08:12 +02:00
Jose Antonio Santos Cadenas
11f298a338 rtpsource: Do not try to push NULL buffers
If update_receiver_stats() fails, we can't really do anything with this buffer
anymore and have to drop it. This happens if there's a big seqnum
discontinuity for example.

https://bugzilla.gnome.org/show_bug.cgi?id=751311
2015-06-22 12:26:59 +02:00
Miguel París Díaz
40957a9212 rtprtxqueue: reverse pending list before pushing buffers
With this we send the RTX buffers in the same order
that they were requested.

https://bugzilla.gnome.org/show_bug.cgi?id=751297
2015-06-22 11:36:22 +02:00
Sebastian Dröge
e9902430da rtpjitterbuffer: gst_rtp_buffer_ext_timestamp() modifies its first argument, keep a copy around 2015-06-16 11:43:39 +02:00
Sebastian Dröge
62a7bcb395 rtpjitterbuffer: Compare ext RTP times, not plain RTP time and ext RTP time when calculating elapsed time
Otherwise all RTP times after a wraparound would be considered as going
backwards, they will always be smaller than the ext RTP time.
2015-06-16 10:31:47 +02:00
Sebastian Dröge
f4e01b13ee rtpbin: The default rtp-profile should be AVP, not AVPF 2015-06-15 19:25:12 +02:00
Sangkyu Park
6696bd62ef rtpjitterbuffer: Minor cleanup
1. Add Null check in 'free_item' function.
2. Fix a typing error of comment.

https://bugzilla.gnome.org/show_bug.cgi?id=750965
2015-06-15 11:55:57 +02:00
Sebastian Dröge
dc513eb949 rtpbin/session: Add new ntp-time-source property and deprecate use-pipeline-clock property
The new property allows to select the time source that should be used for the
NTP time in RTCP packets. By default it will continue to calculate the NTP
timestamp (1900 epoch) based on the realtime clock. Alternatively it can use
the UNIX timestamp (1970 epoch), the pipeline's running time or the pipeline's
clock time. The latter is especially useful for synchronizing multiple
receivers if all of them share the same clock.

If use-pipeline-clock is set to TRUE, it will override the ntp-time-source
setting and continue to use the running time plus 70 years. This is only kept
for backwards compatibility.
2015-06-12 23:35:42 +02:00
Sebastian Dröge
37e3ca1447 rtpbin: Rename some variables and debug output to make more sense
Local and remote were mixed up in a few places, and the time we store here is
not UNIX time (1970 epoch), but NTP time (1900 epoch) in nanoseconds.
2015-06-12 23:07:27 +02: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
Ilya Konstantinov
c7e168ec70 rtpmanager: clarify negative lost packets in stats
Also:
- Move notes on units before field documentation.
- Unify documentation style.

https://bugzilla.gnome.org/show_bug.cgi?id=750653
2015-06-10 14:10:52 +02:00
Ilya Konstantinov
0a578c235a rtpmanager: document units of stats and arguments
Also, minor spelling and style corrections.

https://bugzilla.gnome.org/show_bug.cgi?id=750653
2015-06-09 18:21:59 +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
Sebastian Dröge
8f5bdf9690 rtpjitterbuffer: Add support for receiving reduced size RTCP
It worked before but gave warnings, now we just ignore RTCP
packets that don't start with a SR. As all we're interested
in here are SRs.
2015-06-05 10:33:11 +02:00
Jose Antonio Santos Cadenas
f563176349 rtpssrcdemux: Add support for reduce size rtcp
According to RFC 5506, reduce size packages can be sent, this
packages may not be compound, so we need to add support for
getting ssrc from other types of packages.

https://bugzilla.gnome.org/show_bug.cgi?id=750327
2015-06-05 10:30:15 +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
506a8a8857 rtpbin: Add rtp-profile property for setting the default profile of newly created sessions
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
c60038f188 rtpsource: Queue bad packets instead of dropping them
So we can send them out once we found the next, consecutive sequence number in
case one is following.
2015-05-18 18:43:16 +03:00
Sebastian Dröge
9f18a271f3 rtpsource: Use g_queue_foreach() to unref all buffers in queues 2015-05-18 18:43:16 +03:00
Sebastian Dröge
54e924332e rtpsource: Refactor seqnum comparison code a bit 2015-05-18 18:43:16 +03:00
Sebastian Dröge
1974b24ef4 rtpsource: Allow sequence number wraparound during probation 2015-05-18 18:43:16 +03:00
Sebastian Dröge
3386de7a8a rtpsource: Make sequence number comparison code more readable
... by using gst_rtp_buffer_compare_seqnum() and signed integers
instead of implictly using effects of integer over/underflows.
2015-05-18 18:43:16 +03:00
Sebastian Dröge
ca110fb0b8 rtpjitterbuffer: When detecting a huge seqnum gap, wait for 5 consecutive packets before resetting everything
It might just be a late retransmission or spurious packet from elsewhere, but
resetting everything would mean that we will cause a noticeable hickup. Let's
get some confidence first that the sequence numbers changed for whatever
reason.

https://bugzilla.gnome.org/show_bug.cgi?id=747922
2015-05-18 18:43:15 +03:00
Tim-Philipp Müller
2e412a447a docs: update example pipelines in element docs
Mostly gst-launch -> gst-launch-1.0
Use autovideosink/autoaudiosink more often.
Sprinkle some converters here and there.
2015-05-10 11:05:00 +01: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
73c0c2920f rtpstats: Average RTCP packet size is in bytes, bandwidths in bits
We need to convert the size to bits for our calculations.

https://bugzilla.gnome.org/show_bug.cgi?id=747863
2015-04-27 16:45:40 +02:00
Sebastian Dröge
475b1e607e rtpstats: Use the same lower limit for RTCP bandwidth to stop sending RTCP everywhere
https://bugzilla.gnome.org/show_bug.cgi?id=747863
2015-04-27 16:45:33 +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
9391622579 Rename property enums from ARG_ to PROP_
Property enum items should be named PROP_ for consistency and readability.
2015-04-27 11:22:11 +01:00
Ilya Konstantinov
fd391a5404 rtpjitterbuffer: Fix "stats" property docs
https://bugzilla.gnome.org/show_bug.cgi?id=748436
2015-04-26 21:15:44 +02:00
Tim-Philipp Müller
d753a3eeb1 Remove obsolete Android build cruft
This is not needed any longer.
2015-04-26 17:55:07 +01: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
edcc5be297 rtpjitterbuffer: When request retransmissions for future packets, consider the packet spacing in the extra delay
We now take the maximum of 2*jitter and 0.5*packet_spacing for the extra
delay. If jitter is very low, this should prevent unnecessary retransmission
requests to some degree.

https://bugzilla.gnome.org/show_bug.cgi?id=748041
2015-04-22 20:27:18 +02:00
Sebastian Dröge
3fe8ceff14 rtpjitterbuffer: Take a running average of the packet spacings instead of just the latest
https://bugzilla.gnome.org/show_bug.cgi?id=748041
2015-04-22 20:25:43 +02:00
Miguel París Díaz
f81c9a9568 rtpjitterbuffer: Add "rtx-next-seqnum" property
If this is set to FALSE, rtpjitterbuffer will not request retransmissions for
future packets based on when they are estimated to arrive.

See also https://bugzilla.gnome.org/show_bug.cgi?id=748041

https://bugzilla.gnome.org/show_bug.cgi?id=739868
2015-04-22 19:51:18 +02: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
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