Created attachment 284398 [details]
Log

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.

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").

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

where:
  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;
      else
        /* jitter is in nanoseconds, 2x jitter is a good margin */
        delay = priv->avg_jitter * 2;
    } else {
      delay = priv->rtx_delay * GST_MSECOND;
    }

NEW TIMEOUT CALC. PROPOSAL
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.

Refs
[1] http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtpmanager/gstrtpjitterbuffer.c?id=1.3.3#n1883
[2] http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtpmanager/gstrtpjitterbuffer.c?id=1.3.3#n1696

Created attachment 284521 [details] [review]
A patch to add "rtx-min-delay" property

Review of attachment 284521 [details] [review]:

::: gst/rtpmanager/gstrtpjitterbuffer.c
@@ +130,3 @@
 #define DEFAULT_DO_RETRANSMISSION   FALSE
 #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

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);
    }

Created attachment 284582 [details] [review]
Patch v2

commit bd09dc96e9fa880dcbf94ae5bf6105650fd66733
Author: Wim Taymans <wtaymans@redhat.com>
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 <mparisdiaz@gmail.com>
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.
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=735378

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.