[vlc-devel] RTP jitter buffer does not work
remi at remlab.net
Mon Sep 7 18:02:39 CEST 2009
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.
More information about the vlc-devel