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

Pierre d'Herbemont pdherbemont at free.fr
Thu Jun 5 21:08:05 CEST 2008

On Jun 5, 2008, at 7:32 PM, Rémi Denis-Courmont wrote:

> Le jeudi 5 juin 2008 20:17:13 git version control, vous avez écrit :
>> It is much more efficient regarding latency as it doesn't bufferize  
>> more
>> than needed, and let the module access take care of that eventually.
> Hmm, what about network (or other) jitter?
> Does the ES output takes care of it anyway?

Currently the stream caches as much data as it can. I guess that's to  
make sure we don't loose packet and that we may seek "faster".

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.

Also, seeking is slower because of the latency involved when re- 
buffering, so...

We could cache in an other thread so that we don't block (and  
introduce the latency), but is that really needed?

I think that this caching may have been useful 10 years back, but is  
not anymore.


More information about the vlc-devel mailing list