[vlc-devel] RTP jitter buffer does not work

[Rémi Denis-Courmont]

On Mon, 7 Sep 2009 12:02:39 +0200, Marian Ďurkovič <md at bts.sk> wrote:
>    during testing of some RTP jitter buffer properties it turned out
> that it doesn't work if the jitter value grows to > 5 msec. If this
> happens, RTP input completely stops feeding packets to the demux.
> 
>    Closer investigation shows, that arrival of next packet updates
> src->last_tx with more recent timestamp, and deadline gets recomputed
> again based on this updated info. As a result, the deadline is always
> +5 msec in the future and never expires.

Arg, this is a good catch. We should use the timestamp of the last dequeued 
packet, not the timestamp of the last queued packet.

>   On the other hand, the jitter value on an otherwise idle LAN gets
> as low as 0.2 msec,

The formula is specified by the standard. We cannot change it as such,
without breaking future implementation of RTCP-RR. We can change the 
determination of the reordering window frmo the jitter estimate, but the 
jitter estimate remains the jitter estimate as is.

> which is *way* too low to be of any use for reordering purposes.

That's why the jitter is multiplied by 3 *and* added to the reception time of 
the most recent packet (which was sent later than the late one). So the actual 
receive window is a lot longer than the jitter estimate, if the inter-arrival 
delay variance is small compared to the inter-packet delay itself.

> In 0.8.6 we had 100 msec reordering buffer by default... This
> probably isn't needed today, but something like 10 - 20 msec should be
> the absolute minimum IMHO.

We can cap the delay within minimum and maximum values, say 10 ms to 5 
seconds. But I'm not sure that'll fix anything.
-- 
Rémi Denis-Courmont