[vlc-devel] commit: stream: Add a new method for buffering access: A*Immediate method. (Pierre d'Herbemont )

[Pierre d'Herbemont]

On Jun 5, 2008, at 9:29 PM, Rémi Denis-Courmont wrote:

> Le jeudi 5 juin 2008 22:08:05 Pierre d'Herbemont, vous avez écrit :
>> However, nowadays caching at our level doesn't seems to have a big
>> impact (we are only caching at most 4Mo), and the kernel doesn't seem
>> to trash that much packet, plus disk cache has increased.
>
> 4 Mb is a lot more than the "bandwidth" of typical network jitter. 0  
> Mb is
> infinitely less.
>
> Even sitting idle, my cable modem connection shows about 25ms of  
> packet delay
> variation. That's more than the typical network packetization time  
> (20 ms),
> which is also an intrinsic latency. For audio, 50 ms is not  
> neglectible.
>
> Using TCP, the jitter will be a lot longer due to head-of-line  
> blocking.
>
> Using wireless networking will also increase delay variation.

Well, we don't really care about 25ms variation given that we have a  
pts delay of 900ms, so a really big caching is done much far after in  
the decoding chain.

>> I think that this caching may have been useful 10 years back, but is
>> not anymore.
>
> For disk I/O, it may be irrelevant because the hardware and the  
> operating
> system read ahead. But VLC caching has hidden packet delay variation  
> which is
> inherent to packet switched network (IP). Sure, we could cache a lot  
> less,
> typically some tens of milliseconds, but we can't remove caching.

My point is, this caching isn't relevant as there is a much bigger one  
done afterwards.

Pierre.