How to make MPC-HC to cache more aggressively
The buffer for streamed video in MPC-HC is too small and can't be expanded in user preferences.
Solution 1:
Hacking LAV Splitter to use plain old buffering
LAV Splitter is used to fetch network data in some media players (e.g. MPC-HC). The LAV buffer (aka packets queue) is not measured in data volume, but rather in packets (or frames, not sure here). Anyway, since the network throughput is limited by data volume, the number of packets in queue is multiplied by factor
variable, which is bigger the higher quality video (the audio part actually) you are playing. This provides variable length buffer, however you can't really control the size and if you got slow WiFi you might have experienced choppy playback.
The following guide changes the way LAV buffer works by eliminating packet limits and putting the infamous "Maximum Queue Memory" settings in charge (infamous as you might have tried to increase this settings from default 256 MB to no avail as many have before you).
32-bit instructions
- Open the
mpc-hc/LAVFilters/LAVSplitter.ax
file in HEX editor of your choice. - Find and replace the unique
69 C5 5E 01 00 00
byte sequence with69 C5 FF FF 00 00
. - Open LAV Splitter settings and set the Maximum Queue Memory to 256 MB. This is big enough to deal with flaky WiFi and higher values may introduce instability (above 1 GB for me). But feel free to experiment with this value.
Details
We are changing the m_dwQueueHigh = MAX_PACKETS_IN_QUEUE * factor;
[1] line where #define MAX_PACKETS_IN_QUEUE 350
[2] to m_dwQueueHigh = 65535 * factor;
. This change effectively removes the factor
constraint and Maximum Queue Memory settings won't be capped by it anymore.
How to test it?
Read this answer to find out how big your buffer is now. You are looking for the Buffers: [0] <buffer-size-in-frames>/<buffer-size-in-KB> KB
value.
When this is not enough?
This hack basically enlarges the cache limit 187 times (65535 / 350
). In most cases this is enough and the limiting factor is what you set in Maximum Queue Memory. In some rare cases it might not be the case
- if you would play very long video, the number of cached frames
65535 * factor
could be lower than number of all frames in the video file. - if you would play very low quality video, the
frame size in MB * 65535 * factor
could be lower than your Maximum Queue Memory.
factor
is in range from 2
to 120
(source).