diff options
| author | Stian Selnes <stian@pexip.com> | 2016-07-27 10:39:50 +0200 |
|---|---|---|
| committer | Olivier Crête <olivier.crete@collabora.com> | 2016-09-14 19:37:50 -0400 |
| commit | 2eb73838168e1cac9ea23430b3e288cc63101e6e (patch) | |
| tree | 4acd25819b966e9a034261e9bb1ba4860cbbcc17 /gst | |
| parent | ab49dfd0b209a5dec10ce9cc8b84ae86dc1e8779 (diff) | |
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
Diffstat (limited to 'gst')
| -rw-r--r-- | gst/rtpmanager/gstrtpjitterbuffer.c | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/gst/rtpmanager/gstrtpjitterbuffer.c b/gst/rtpmanager/gstrtpjitterbuffer.c index c3ab683f5..57f3e9769 100644 --- a/gst/rtpmanager/gstrtpjitterbuffer.c +++ b/gst/rtpmanager/gstrtpjitterbuffer.c @@ -3632,7 +3632,8 @@ do_expected_timeout (GstRtpJitterBuffer * jitterbuffer, TimerData * timer, GST_TIME_ARGS (timer->rtx_retry), timer->num_rtx_retry); if ((priv->rtx_max_retries != -1 && timer->num_rtx_retry >= priv->rtx_max_retries) - || (timer->rtx_retry + timer->rtx_delay > rtx_retry_period)) { + || (timer->rtx_retry + timer->rtx_delay > rtx_retry_period) + || (timer->rtx_base + rtx_retry_period < now)) { GST_DEBUG_OBJECT (jitterbuffer, "reschedule as LOST timer"); /* too many retransmission request, we now convert the timer * to a lost timer, leave the num_rtx_retry as it is for stats */ |