Commit graph

336 commits

Author SHA1 Message Date
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Miguel París Díaz
c4bb6a098b rtpjitterbuffer: Add "rtx-max-retries" property
This property allows to limit the maximum number of retransmission
for a specific packet.

https://bugzilla.gnome.org/show_bug.cgi?id=739868
2015-04-13 09:09:03 +02:00
Miguel París Díaz
05bd708fc5 rtpjitterbuffer: Fix expected_dts calc in calculate_expected
Right above we consider lost_packet packets, each of them having duration,
as lost and triggered their timers immediately. Below we use expected_dts
to schedule retransmission or schedule lost timers for the packets that
come after expected_dts.

As we just triggered lost_packets packets as lost, there's no point in
scheduling new timers for them and we can just skip over all lost packets.

https://bugzilla.gnome.org/show_bug.cgi?id=739868
2015-04-13 09:06:33 +02:00
Sebastian Dröge
1a2f253c3a rtpjitterbuffer: Make the next output buffer discont after resetting the jitterbuffer
Resetting the jitterbuffer drops all packets and other things, and will cause
a discontinuity in the packets received by the depayloaders. They should now
also flush anything they had pending as the new data will start at a different
position.

https://bugzilla.gnome.org/show_bug.cgi?id=739868
2015-04-13 09:05:34 +02:00