MPC-HC Not Caching Aggressively Enough

[quasi51]

This is part 2 of my "streaming 1080p over Wireless N" dilemma. Initially when streaming 1080p MKV files over my wireless N network, MPC-HC starting stuttering immediately. However, I narrowed it down to a codec problem which I've resolved.

Now MPC-HC plays the movie perfectly but only for about 2 minutes, then it begins to stutter. If I pause it for a few seconds and then resume it plays again for a few more minutes and then starts to stutter.

It appears (to me) that MPC-HC creates a cache when I first start the movie but fails to maintain that cache and is forced to re-buffer after a few minutes. The issue is not a lack of bandwidth on the wireless network. I can move files over the network at 100mbps all day long (real transfer rate, not link speed). The movie in question is encoded at about 15mbps so I have over 6x the bandwidth I need. Even if the network slows occasionally there is no reason why MPC-HC shouldn't be able to keep an adequate cache.

Is there a way to manually specify a cache value for MPC-HC to keep...something like mplayer's -cache/-cache-min options? I'm open to trying other players but I'd prefer to use MPC-HC or something that uses directshow/WMF. Or is there a way to tell MPC-HC to maintain it's cache more aggressively? Perhaps a command line option?

:thanks: in advance for your responses

[peek]

Not sure if this could help to solve your problem, but did you already try to increase the input buffer size of the Haali Media Splitter. On my system I've set it to 100000 instead of just 8192 and this avoids A/V sync losses. Maybe it can also improve your streaming?

[clsid]

MPC-HC does not buffer anything, the splitter does.

[kieranrk]

For the internal splitters there a hardcoded buffer amount in the source code.

[quasi51]

Thanks for all of the above replys, I didn't realize the buffering happened in the splitter. I'll adjust the setting for the Haali splitter and see what happens.

[Jong]

It's true, mpc-hc does not stream effectively using its internal splitters. Just as the OP suggests, it is like it does not even keep refilling its buffer. It just seems to empty it, then pause while it refills. I suspect a bigger buffer would just mean a longer wait 'till it starts and a longer pause while it refills.

I stream Apple Trailers from my HTPC front-end (MeediOS) and I have had to switch to using smplayer for http, which is not ideal because it will not work with Reclock.

[tetsuo55]

I consider the internal splitters as non-buffering, the buffering logic and size needs to be greatly improved.

[clsid]

For files played from a network share it could help to increase the buffer size in MPC code.

[tetsuo55]

Do you know which section of code to change?

Maybe one of you can open a ticket on the tracker and explain what the requirements are: http://sourceforge.net/apps/trac/mpc-hc/wiki/How_to_Report_Issues

[JohnPeterson]

It appears (to me) that MPC-HC creates a cache when I first start the movie but fails to maintain that cache and is forced to re-buffer after a few minutes.
The Haali (1.10.175.0) input buffer seems to do the same. It fills the buffer as fast as it can, in my case around 1.7 MB/s. Then the read speed goes down to 0.0-0.3 MB/s and it lets the buffer run to 0 or close to 0, which is wrong, it should always be buffering if the buffer is smaller than the buffer size from the input buffer setting.

Another annoying thing is that when the H264 codec doesn't get enough data (which happens when the buffer run out) it almost completely locks Windows for about 60 seconds by overwhelming Windows with CPU demand (from either mpc-hc.exe or wmplayer.exe depending on which you use), then starts playback again (with the audio around 60 seconds ahead, and with a choppy video, but that's not the big problem, the lockup is more annoying). The exact same lockup happens with WMP+ffdshow or MPC-HC with internal filters.

So I would need a working buffer to be able to reliably play back HD video over wireless. I'm guessing the buffering happens in http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/filters/parser/MatroskaSplitter/MatroskaSplitter.cpp. But I can't locate it.

[leeperry]

I would need a working buffer to be able to reliably play back HD video over wireless.
you could try KMP's cache: http://thumbnails21.imagebam.com/9000/74a06c89999860.jpg (http://www.imagebam.com/image/74a06c89999860)

[JohnPeterson]

you could try KMP's cache
Thanks, KPM seems to work better in this regard, it seems less likely to run out of buffer and lock up in a stutter during continuous playback. However jumping works almost as bad as in MPC-HC, after a few jumps it will enter a 60 seconds - 120 seconds stutter lock-up (with 100% CPU load that locks up everything). And if it enters the stuttering lockup it will never recover from it fully but keep reentering it over and over with a few seconds in between, so I have to restart the program. But it's less likely to end up in a stutter than MPC-HC so I'll use KMP instead of MPC-HC with wireless for now.

It's however clear that neither MPC-HC or KMP are designed to cope with a slow source medium. The stuttering lockup loop that it places the avc1 decoder in when it temporarily lacks source data is an outright bug. It's probably a problem with a low latency dependence when jumping to a new frame, somewhere the code assumes that sufficient data is available immediately, when it may not be, and if there is a few many ms latency it will enter the stuttering lockup loop, and the async file read doesn't seem to help prevent that at all.

[Chengbin]

I have this problem as well. The jumping problem was so annoying I reverted back to good old ethernet cable.

[SithUK]

I have found a fix to the stuttering issue.

The stuttering issue is due to the buffer size not being the 256MB set under "Maximum Queue Memory" in the splitter settings (view->options->internal filters). I observed a significantly smaller buffer size of approximately 10MB instead of 256MB.

The smaller buffer size was insufficient to deal with the performance variability over my wireless network.

The fix involves using a hex editor to modify the LAVSplitter.ax file in the LAVfilters subfolder of the MPC-HC installation folder. The details of the fix are at the following link.

http://superuser.com/questions/842203/how-to-make-mpc-hc-to-cache-more-aggressively

I have carried out the fix on version 1.7.7 of MPC-HC and can verify that it resolved my buffering issue. I can see that the program is buffering 256MB instead of approximately 10MB when I turn on "statistics" (view->statistics).

Playback performance has been rock solid since.

[ryrynz]

Should post about it in the LAV forum, no doubt other users could benefit from this and Nev might be able to add an option.

[djonline]

Will it be fixed in newer version of LAV ? It can be option inside LAV.

[ryrynz]

Will it be fixed in newer version of LAV ? It can be option inside LAV.

This has just been added to LAV. It'll be in the next nightly.

[clsid]

It would be interesting to know the minimum value required for the new "Maximum Queue Packets" setting for you guys to get smooth playback.

[nevcairiel]

Setting anything below 50 will probably not actually work, as there is a fallback to ensure a minimum number of packets in the cache, although on a fast system with good IO, you could probably get away with no buffering at all, assuming the file is also properly interleaved.
The buffering doesn't only protect against IO hiccups, but also against bad files where the corresponding video and audio may be too far apart.

[clsid]

I meant for smooth streaming over WiFi. The default value (350) is too small in that case, at least for topic starter.

I assume its 1 packet per video frame? So a 30 second buffer is roughly 720 packets.