Mpv: Default buffer/cache too small?

[Pacoup]

I have been having this issue with mpv where on disk resource starved systems (e.g. installing software, copying media, slower HDD, USB HDD), mpv skips every so often (noticeable video and audio skip).

I'm under the impression this is related to the buffer/cache (however you call it internally) which is not big enough, causing mpv to load and seek quickly, arguably, but also causing these skips, which are a far worse issue than a few added milliseconds while buffering more content.

This might seem unreasonable, but the thing is, it happens quite often. I've had to switch to other players on a number of systems (both OS X and Windows, never tested Linux) because mpv skips with the combination of high quality HD content and low disk bandwidth.

Of course, I've never had this issue on an SSD-based systems, but that's besides the point. It merely highlights the issue.

You _could_ make it an option, but then that's a setting most users don't understand, which means anyone without a perfect watching environment / SDD would encounter playback skips in mpv.

Further proof to my claims, even though I don't have hard data: if I seek back in the same clip to just before the skip happened and play it back, the skip doesn't happen anymore, so it's not a playback clip.

Doing anything which hammers the disk also reproduces the same effect, while other players take much more before they start having playback issues. So, RAM-buffered video/audio issue.

I could be wrong, but if this is the case, in terms of balancing load/seek performance and cache sizes, wouldn't it be a better idea to decouple video/audio buffers such that video can be allowed to skip earlier while audio continues to play back correctly (although it might be the case right now, but so far mpv has been consistently cutting both audio and video at the same time, so I'm assuming they're tied, unlike, in, say, how QuickTime behaves).

[ghost]

mpv by default doesn't use any cache, and expects that the kernel does a good job with prefetching (which apparently is only the case on Linux, but not Windows or OSX).

You can enable the cache manually with --cache=123 where 123 is the cache size in kilobytes,

[Pacoup]

Isn't that a compile switch? What about binary release users.

@ChrisK2 @lachs0r
You guys think it would be possible to modify your binaries to include a default setting for this to accomodate users of these platforms?

@wm4 You're not really solving the issue -- default cache -- by saying Linux does it right. Your player still has playback issues on other platforms you are supposedly supporting.

[kevmitch]

This is a command line, not compile time option. You can also put "cache=123" in your mpv/config file, which is a common thing to do even in Linux.

[Pacoup]

Oh. Apologies for my ignorance.

Em, does this mean an mpv-based player could offer those settings in a GUI?

[ghost]

Yes.

Anyway, I definitely don't want to enable this on Linux. It works fine even if the disk is slow (think old fragmented harddisk), and enabling cache actually makes seeking slower (because it reads more data, just to discard it immediately).

[ghost]

PS: the situation might improve as soon as mpv runs demuxer and decoders on separate threads, but until this happens some time will pass. I'll leave it to others whether it should be enabled by default on Windows or OSX.

[eiennohito]

For me cache of 4mb fixed stuttering when playing a file from windows share on OSX

[pigoz]

Btw, in master mpv on OSX will autoenable for files on remote mounts.

[runeksvendsen]

FYI, I'm running Linux and the cache size isn't sufficient when there is heavy disk activity (rotational HDD). I'm watching an average 6 mbit 1080p x264 video, and in the first one minute there are 45 frame drops, usually coming in clusters of 5-10 frames at one time.

This happens when the HDD is being backed up via rsync, which is done automatically every day.

Not sure if this is reason enough for increasing the default cache size in mpv, but I just wanted to let you know it happens on Linux as well (during heavy disk activity).

[ghost]

Any suggestions for a better default cache size?

[ghost]

Also, how to handle the various cache options:

• how much data to cache before starting playback at all
• threshold between performing a seek or waiting until the data arrives when seeking a bit forward
• when to temporarily pause playback on low cache

[ghost]

Anyway, enlarged the default cache size to about 25MB.

For local files (on local filesystems), it still doesn't use a cache by default, though.

[tetherit]

Doesn't seem to recognise FUSE based mounts on OSX like SSHFS has no cache which causes freezes during playback :(

[qmega]

@hackeron Whatever fs type name fuse/sshfs uses on OSX should be added here. I think it would be fuse.sshfs, but my BSD machine is down ATM so I can't test.

Try this:

diff --git a/stream/stream_file.c b/stream/stream_file.c
index d0da862..8dfc6bb 100644
--- a/stream/stream_file.c
+++ b/stream/stream_file.c
@@ -158,7 +158,7 @@ char *mp_file_get_path(void *talloc_ctx, bstr url)
 static bool check_stream_network(int fd)
 {
     struct statfs fs;
-    const char *stypes[] = { "afpfs", "nfs", "smbfs", "webdav", NULL };
+    const char *stypes[] = { "afpfs", "nfs", "smbfs", "webdav", "fuse.sshfs", NULL };
     if (fstatfs(fd, &fs) == 0)
         for (int i=0; stypes[i]; i++)
             if (strcmp(stypes[i], fs.f_fstypename) == 0)

If that doesn't work, you'll have to figure out the correct name. You can probably see that by just running mount without arguments, or you could use something like this little program.

[tetherit]

@qmega unfortunately statfs just shows osxfusefs:

# ./statfs /Volumes/Archive 
osxfusefs

[ghost]

So which is it?

Enabling caching for all fuse filesystems would probably be ok.

[tetherit]

Enabling for all fuse filesystems would be my vote :)

[qmega]

Well, that's how it is on Linux right now, so for consistency's sake I'd say yes, "osxfusefs" should probably be added to the network stream type list.

[ghost]

We have an additional cache layer (the demuxer cache), so I'd consider such problems with local I/O almost impossible, unless the bitrate is close to what the disk can deliver. Such audio stutters are more likely to be an audio output problem now. Maybe too small buffer or so.

[drojf]

Windows user here, getting short audio stutter occasionally, even with local playback. I haven't had any problems with other programs - I'll enable the cache and report back in a couple months if I remember :).

[drojf]

Wow thanks for the quick reply. I found the audio buffer settings, I'll see if it makes any difference. I think my computer/setup is particularly bad - I ran "LatencyMon" and it reported some issues (sorry, I didn't save a log file for the last time I ran it). However I don't wanna say it's 100% that since playback on other programs is seemingly OK (mainly youtube videos on chrome, no issues there).

http://www.resplendence.com/latencymon

edit 27-05-2018:
Followup: I've never had any audio stutters on any mpv version I've used for the past year.

[ghost]

It could be our own buffer settings, maybe even those that can't be changed by the user.

Maybe @kevmitch knows what you could test here.

[brunogm0]

In Linux please use BFQ io-scheduler much better soft-realtime latency and
throughtput. Here a demonstration when playing video:
https://youtu.be/J-e7LnJblm8?t=570

2016-05-05 10:41 GMT-03:00 V. Lang [email protected]:

It could be our own buffer settings, maybe even those that can't be
changed by the user.

Maybe @kevmitch https://github.com/kevmitch knows what you could test
here.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/mpv-player/mpv/issues/634#issuecomment-217157274

[Webbeh]

Hi.

Any reason why caching is disabled per default for cdda ?

It's not only hidden. Withouth the manual --cache option, the audio would cut for 1 second every 10-15 seconds and rebuffer. The disk drive would spin fast for a few seconds, then IDLE, etc.

No issue with 4M of cache.

[cplayer] mpv git-8ffd2f1 (C) 2000-2016 mpv/MPlayer/mplayer2 projects
[cplayer] built on Tue Apr 26 14:04:04 CEST 2016

[gall0ws]

Would be possible to add support for other BSDs? In this scenario on OpenBSD fstypename is
"fuse" and on FreeBSD is "fusefs.sshfs".

[jnihil]

I've seen mpv stutter during high disk IO from other tasks, Ubuntu 20.04.
Adding the cache config of 10240 has stopped all stuttering. Thanks for the tip.
BTW, I have absolutely no seek issues even with this cache setting.