[vlc-devel] RTP jitter buffer does not work

Marian Ďurkovič md at bts.sk
Mon Sep 7 21:09:49 CEST 2009


On Mon, 7 Sep 2009 18:02:39 +0200, Rémi Denis-Courmont wrote
> Arg, this is a good catch. We should use the timestamp of the last 
> dequeued packet, not the timestamp of the last queued packet.

Yep, your commit 4f49f2aac62b4459cf75f3c593e4ee2e52b2f921 fixes this fine.


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

Well, after the above change, we now only have 3*jitter left, i.e. 3*0.2 msec.
Reordering happens due to variable buffering delay in multiple paths (either in
the network or inside the hardware), so we need much more here. I'd propose
25 msec as min and rtp-caching/4 (250 msec) as max, since there's no point in
creating decoder FIFO underruns.


   With kind regards,

        M.



> -- 
> Rémi Denis-Courmont
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel




More information about the vlc-devel mailing list