Как заставить MPC-HC кешировать более агрессивно

18031
Vlastimil Ovčáčík

Буфер для потокового видео в MPC-HC слишком мал и не может быть расширен в пользовательских настройках.

4

1 ответ на вопрос

4
Vlastimil Ovčáčík

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

  1. Open the mpc-hc/LAVFilters/LAVSplitter.ax file in HEX editor of your choice.
  2. Find and replace the unique 69 C5 5E 01 00 00 byte sequence with 69 C5 FF FF 00 00.
  3. 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).

[Это] (http://superuser.com/a/842244/238468) - хороший способ проверить это. Vlastimil Ovčáčík 9 лет назад 2
После 4 месяцев использования это полностью устранило эффект моего нестабильного WiFi на воспроизведении. Стабильно до 1 ГБ «Максимальной памяти очереди», тогда могут произойти сбои. Vlastimil Ovčáčík 9 лет назад 3
Это также исправляет болтовню SVP! FelikZ 8 лет назад 1
@FelikZ, я знаю, что вы имеете в виду, торгуя 100 МБ ОЗУ для плавного воспроизведения - это совсем не высокая цена. Это может быть намного проще, хотя, с одной маленькой галочкой в ​​настройках ... Понятия не имею, что такое болтовня SVP. Vlastimil Ovčáčík 8 лет назад 0
Спасибо за это! По какой причине вы не сделали это в 64-битной версии? У меня есть несколько видео размером> 1 ГБ, но я не уверен, что можно увеличить их больше, чем «FF FF», не сломав что-либо. Christopher Markieta 8 лет назад 0
@ ChristopherMarkieta, пожалуйста, и да, у меня нет 64-битной Windows под рукой. Часть `FF FF` уже достаточно высока, чтобы снять любые ограничения, я имею в виду, что вы не получите ничего при более высоком значении, даже если бы это было возможно. Размер кэша определяется значением * Maximum Queue Memory *, где я рекомендую 256 МБ. Вы можете пойти выше, но я видел некоторую нестабильность выше 1 ГБ, протестируйте ее. Я не собирался воспроизводить целые видеофайлы из памяти (хотя вы могли бы), а скорее кэшировать достаточное количество видеофайлов, чтобы выдержать колебания в моем нестабильном WiFi. Vlastimil Ovčáčík 8 лет назад 0
@ VlastimilOvčáčík У меня для Max Queue Mem установлено значение 4096 для этого случая, я хочу кэшировать все видео в памяти, потому что у меня другая проблема с моим вялым домашним сервером, и Samba иногда зависает. Но это решение действительно помогло уменьшить мои проблемы и было довольно увлекательным. Еще раз спасибо! Christopher Markieta 8 лет назад 1
@ChristopherMarkieta спасибо, что поделились этим, я нахожу интересным, что вы работаете с 4 ГБ кеша. С такими высокими значениями вы, возможно, захотите следовать новому разделу * Как проверить это *, чтобы быть уверенным, насколько большой у вас кэш. Vlastimil Ovčáčík 8 лет назад 0
Я заметил, что мой кэшировать все же ограничивает до примерно 260, 000 кБ ̶ (̶ ~ 256 МБ? ̶) ̶, ̶ с числом кадров, изменяющемся от 7, 000 ̶-̶ 30, 000 ̶ (вместо 350) ̶ в зависимости от ̶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̶? ̶ Похоже, понижение моей Max Queue Mem увеличило размер буфера. Возможно, 32-битное ограничение как-то? Было бы приятно увидеть, как это работает в 64-битной версии. Christopher Markieta 8 лет назад 0
Но я не совсем уверен, как вы нашли последовательность байтов для этого. :П Christopher Markieta 8 лет назад 0
@ChristopherMarkieta понижение максимальной очереди памяти не должно иметь такого эффекта. Не совсем уверен, что посоветовать. Я использовал [декомпилятор IDA] (https://www.hex-rays.com/products/ida/support/download_freeware.shtml). Vlastimil Ovčáčík 8 лет назад 0
Я пробовал это, но это не работает. `69 C5 5E 01 00 00` не найден в файле. Hikari 7 лет назад 0
@Hikari Мне жаль это слышать. Это означает, что у вас другая версия библиотеки LAV или 64-битная версия. К сожалению, у меня нет времени, чтобы обновить это руководство. Vlastimil Ovčáčík 7 лет назад 0
Все нормально. Я просто сообщаю, что это больше не работает. Я благодарю всех, кто умеет находить новые коды. Hikari 6 лет назад 0

Похожие вопросы