After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 735378 - gstrtpjitterbuffer: requests retransmission periodically when no needed
gstrtpjitterbuffer: requests retransmission periodically when no needed
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2014-08-25 12:42 UTC by Miguel París Díaz
Modified: 2014-10-22 17:55 UTC
See Also:
GNOME target: ---
GNOME version: ---

Log (64.21 KB, text/plain)
2014-08-25 12:45 UTC, Miguel París Díaz
A patch to add "rtx-min-delay" property (3.83 KB, patch)
2014-08-26 16:27 UTC, Miguel París Díaz
needs-work Details | Review
Patch v2 (3.88 KB, patch)
2014-08-27 08:25 UTC, Miguel París Díaz
committed Details | Review

Description Miguel París Díaz 2014-08-25 12:42:38 UTC
I have noticed that gstrtpjitterbuffer requests retransmission periodically when no needed (if "do-retransmission" is set).

I have traced the code and I suppose that it is a bug in the timers/timeouts management.
For more info, when the RTP sender receives a NACK can not match the expected seqnum because it is not generated yet.

I attach a log when this can be seen. Search for "<rtpjitterbuffer0> timeout".
Comment 1 Miguel París Díaz 2014-08-25 12:45:38 UTC
Created attachment 284398 [details]
Comment 2 Miguel París Díaz 2014-08-26 13:18:09 UTC
Sorry for this message, I have already seen that the problem is that I had the jitterbuffer with the default configuration.
Setting “rtx-delay” to 20ms I have the expected behavior.
Comment 3 Miguel París Díaz 2014-08-26 16:26:15 UTC
Hello again,
I have been thinking about my problem and it is derived when the network jitter approaches 0 (for example in a lo network, where I am doing my tests).

This causes retransmission requests for packets not generated yet by the sender, for example in the case where the sender are capturing and enconding video, which can add oscillations in the frames generation ("media jitter").

JitterBuffer set the time out as follow (see [1] and [2]):
  timeout = expected + delay;

  expected = dts + priv->packet_spacing;

  and delay depends on the config:
    if (priv->rtx_delay == -1) {
      if (priv->avg_jitter == 0)
        delay = DEFAULT_AUTO_RTX_DELAY;
        /* jitter is in nanoseconds, 2x jitter is a good margin */
        delay = priv->avg_jitter * 2;
    } else {
      delay = priv->rtx_delay * GST_MSECOND;

If we set “rtx-delay”, we loss the 2x jitter usage for the delay, which it is useful.
So, I propose a new attr named "rtx-min-delay", which set the minimum time in ms to wait before sending retransmission event.
I attach a patch where you can see it with more details.

Comment 4 Miguel París Díaz 2014-08-26 16:27:37 UTC
Created attachment 284521 [details] [review]
A patch to add "rtx-min-delay" property
Comment 5 Sebastian Dröge (slomo) 2014-08-27 07:23:38 UTC
Review of attachment 284521 [details] [review]:

::: gst/rtpmanager/gstrtpjitterbuffer.c
@@ +130,3 @@
 #define DEFAULT_RTX_DELAY           -1
+#define DEFAULT_RTX_MIN_DELAY       0

Shouldn't this have a non-zero default? If I understand your problem correctly the code currently sends rtx requests immediately if the packet did not arrive at the expected time. And the expected time does not have any tolerance for jitter or anything in the network or producer.

@@ +545,3 @@
+   * GstRtpJitterBuffer:rtx-min-delay:
+   *
+   * When a packet did not arrive at the expected time, wait al least this extra amount

typo: al -> at

@@ +548,3 @@
+   * of time before sending a retransmission event.
+   *
+   * Since: 1.3

Since: 1.6
Comment 6 Miguel París Díaz 2014-08-27 08:24:31 UTC
I think that by default this should be 0 and the application layer should set the value that it estimates, because this min_delay should depend on the nature of the media.
We can also use "latency" property as default value.

I upload a new patch fixing your comments. Also I check that rtx_min_delay is greater than 0 before using it for efficiency:

    if (priv->rtx_min_delay > 0) {
      delay = MAX (delay, priv->rtx_min_delay * GST_MSECOND);
Comment 7 Miguel París Díaz 2014-08-27 08:25:04 UTC
Created attachment 284582 [details] [review]
Patch v2
Comment 8 Wim Taymans 2014-10-22 13:06:20 UTC
commit bd09dc96e9fa880dcbf94ae5bf6105650fd66733
Author: Wim Taymans <>
Date:   Wed Oct 22 15:04:24 2014 +0200

    rtpjitterbuffer: limit the retry frequency
    When the RTT and jitter are very low (such as on a local network), the
    calculated retransmission timeout is very small. Set some sensible lower
    boundary to the timeout by adding a new property. We use the packet
    spacing as a lower boundary by default.

commit 4b5243c43d8c6e3948f363406760f3eaa8a42a0d
Author: Miguel París Díaz <>
Date:   Wed Oct 22 13:40:58 2014 +0200

    gstrtpjitterbuffer: add "rtx-min-delay" property
    This property is useful to set a min time to wait before sending a
    retransmission event.
Comment 9 Wim Taymans 2014-10-22 13:08:29 UTC
I pushed two patches:

 1) this patch, which limits the delay before sending the first RTX request
 2) one to limit the retry frequency on low-latency networks. It was a similar
    problem but about the interval used to retry the RTX request.