6
8
The buffer for streamed video in MPC-HC is too small and can't be expanded in user preferences.
6
8
The buffer for streamed video in MPC-HC is too small and can't be expanded in user preferences.
5
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).
mpc-hc/LAVFilters/LAVSplitter.ax
file in HEX editor of your choice.69 C5 5E 01 00 00
byte sequence with 69 C5 FF FF 00 00
.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.
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.
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
65535 * factor
could be lower than number of all frames in the video file.frame size in MB * 65535 * factor
could be lower than your Maximum Queue Memory.factor
is in range from 2
to 120
(source).
2This is a good way to test it. – Vlastimil Ovčáčík – 2014-11-19T15:01:31.600
3After 4 months of usage, this completely removed the effect of my flaky WiFi on the playback. Stable up to 1 GB of "Maximum Queue Memory", then crashes may occur. – Vlastimil Ovčáčík – 2015-03-29T10:02:36.620
1It also fixes
SVP
chattering! – FelikZ – 2015-05-22T19:51:14.070@FelikZ, I know what you mean, trading 100 MB of RAM for smooth playback is not high price at all. This could get lot easier though, with one small tickbox in settings... No idea what SVP chattering is. – Vlastimil Ovčáčík – 2015-05-22T19:53:28.700
Thanks for this! Any reason you didn't do this in 64-bit? I have some videos that are > 1GB but not sure if you can increase more than
FF FF
without breaking something. – Christopher Markieta – 2015-12-05T20:04:18.070@ChristopherMarkieta you are welcome and yes, I don't have 64 bit Windows at hand. The
FF FF
part is already high enough to remove any constraints, I mean you wouldn't gain anything by higher value, even if it was possible. The cache size is determined by Maximum Queue Memory, where I recommend 256 MB. You can go higher, but I saw some instability above 1 GB, test it. It wasn't my point to playback whole video files from memory (although you could), rather to cache enough of the video file to survive ripples in my flaky WiFi. – Vlastimil Ovčáčík – 2015-12-07T07:34:39.0471@VlastimilOvčáčík I have Max Queue Mem set to 4096 for this case, I wish to cache the entire video in memory because I am having another issue with my crummy home server and Samba occasionally hangs. But this solution really helped reduce my problems and was quite fascinating. Thanks again! – Christopher Markieta – 2015-12-07T08:23:17.760
@ChristopherMarkieta thanks for sharing that, I find interesting you got it working with 4 GB cache. With values this high you may want to follow the new How to test it section to be sure how big cache you got. – Vlastimil Ovčáčík – 2015-12-07T09:03:00.137
I̶ ̶n̶o̶t̶i̶c̶e̶d̶ ̶t̶h̶a̶t̶ ̶m̶y̶ ̶c̶a̶c̶h̶e̶ ̶s̶t̶i̶l̶l̶ ̶l̶i̶m̶i̶t̶s̶ ̶t̶o̶ ̶a̶b̶o̶u̶t̶ ̶2̶6̶0̶,̶0̶0̶0̶ ̶K̶B̶ ̶(̶~̶2̶5̶6̶ ̶M̶B̶?̶)̶,̶ ̶w̶i̶t̶h̶ ̶t̶h̶e̶ ̶n̶u̶m̶b̶e̶r̶ ̶o̶f̶ ̶f̶r̶a̶m̶e̶s̶ ̶v̶a̶r̶y̶i̶n̶g̶ ̶f̶r̶o̶m̶ ̶7̶,̶0̶0̶0̶ ̶-̶ ̶3̶0̶,̶0̶0̶0̶ ̶(̶i̶n̶s̶t̶e̶a̶d̶ ̶o̶f̶ ̶3̶5̶0̶)̶ ̶d̶e̶p̶e̶n̶d̶i̶n̶g̶ ̶o̶n̶ ̶t̶h̶e̶ ̶v̶i̶d̶e̶o̶ ̶q̶u̶a̶l̶i̶t̶y̶.̶ ̶I̶s̶ ̶t̶h̶a̶t̶ ̶s̶t̶r̶a̶n̶g̶e̶?̶ Looks like lowering my Max Queue Mem has increased the buffer size. Possibly a 32-bit limitation somehow? Would be nice to see how it works in 64-bit. – Christopher Markieta – 2015-12-07T14:47:35.423
But I'm not quite sure how you found the byte sequence for this one. :P – Christopher Markieta – 2015-12-07T14:53:05.213
@ChristopherMarkieta lowering Maximum Queue Memory should not have that effect. Not quite sure what to advise. I have used IDA decompiler.
– Vlastimil Ovčáčík – 2015-12-07T17:12:45.773I tried this but it doesn't work.
69 C5 5E 01 00 00
isn't found on the file. – Hikari – 2016-12-31T16:47:20.423@Hikari I'm sorry to hear that. That means you have different version of LAV library or 64 bit version. Unfortunately I don't have time to update this guide. – Vlastimil Ovčáčík – 2017-01-01T07:57:48.400
It's ok. I'm just reporting that it doesn't work anymore. I thank anyone with skills to find the new codes. – Hikari – 2017-06-19T17:29:52.027