The VideoLAN Forums

I am attempting to watch a rather high bitrate hi10p h.264 file, but unfortunately, there are some brief parts (TV static, animated confetti, etc.) which are too strenuous for my aging dual core laptop to handle. Most of the film is rather tame and my CPU trudges along at 60-70% utilization. I don't intend to do much seeking, and I suspect that if I could just throw a gig or so of RAM at the problem my machine would be able to hold its breath through the noisy sections.

Unfortunately, I don't see an option for that. Does anyone know where that option is or, if it doesn't exist, whether it is in the works?

VLC computes the number of required pictures based on the codec parameters. That should not need fixing.

More memory will not fix insufficient computational power.

It will, however, fix underutilization of computational power. During low-information sections of the video, there is a substantial surplus of CPU cycles which could be used to decode further ahead and buffer YUV frames in memory. Yet there are cycles unused and memory free, but frames still not decoded in time.

Presumably, the heuristics used to compute the number of frames were chosen to make a tradeoff between throughput, seek latency, and memory footprint. I would like to shift the balance of that tradeoff.

There are not much room for heuristics there. The number of picture buffers allocated by VLC is based on the number of reference frames potentially required by the video codec. This comes from the codec specification.

Actually, very often, the decoder pool size amounts to 20 pictures (VOUT_MAX_PICTURES hardcoded parameter). Only demanding codecs are likely to increase this upper limit (dpb_size parameter).

In particular, the cache size (file-caching parameter and the likes) is not taken into account when sizing this decoder pool. When a user sets a high cache value,the bulk of the data is buffered but not decoded. Data is waiting in the decoder fifo, and the decoder is blocked waiting for a free picture from the decoder pool. Just increase the VOUT_MAX_PICTURES value and more pictures from the cache will be decoded ahead of time. Maybe seasoned users could be given the possibility to set this parameter ?

As a side note, I tested it for quite a different purpose. With powerful computers (cpu/gpu/memory), why not set this parameter to a high value and delay picture release till the decoder pool runs out of free pictures. This way, a history of past pictures can be retained. It can be used for a backward frame-by-frame mechanism similar to the forward one. For vout drivers like x11, this parameter is the only limit since it is system memory allocation. For others like Opengl, they may force their own upper limit (for instance, a max of 128 direct buffers is hardcoded for Opengl). These tests worked very fine with several seconds worth of history for backward frame-by-frame.