[vlc-devel] commit: Increased fifo decoder size to 400mb. (Laurent Aimar )

[Rémi Denis-Courmont]

Le dimanche 25 octobre 2009 01:17:01 Laurent Aimar, vous avez écrit :
>  Have you ever seen it in action... ?
>  There is a lot of place where we don't limit memory usage, this one is an
> exception.

There are many places where we don't put limits. But typically we allocate one 
or a few large chunks. If it's really big, we'll just get a NULL. Failing on 
corrupted streams is fine anyway.

The ES FIFO accumulates small packets overtime, which is much more likely to 
"succeed" but slow the system down to an almost complete halt. There is indeed 
another known caseof unbound FIFO: the now understood but still unfixed muxer 
OOM bug when one of the ES is dead but not the other ones. That is quite 
problematic, but it only affects streaming output.

> The only time I have seen it being activated, is on valid files
> (raw video), on really high caching values, and when I was working on the
> core (bugs in input/codec).
> 
> > >  As there is no really good fixed value, I simply but a very large one
> > >  (mainly for devs working on the input/decoder).
> >
> > No. 40 Mb was a good value. Something is seriously wrong if you need to
> > cache 500 Mb of coded data on a single E/S, even at HD resolutions.
> 
>  I increased it because 40 Mb is too low (typically with raw HD video), now
>  400Mb may be a bit too high, but I don't want to break the playback of
>  valid files.

IMHO, there is a difference between a valid file and a valid input. Something 
is terribly broken if you need 500 Mb of cached data to play a file correctly. 
Maybe, the file is valid, but then the access protocol is misused.

-- 
Rémi Denis-Courmont
http://www.remlab.net/