New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Default buffer/cache too small? #634
Comments
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 |
Isn't that a compile switch? What about binary release users. @ChrisK2 @lachs0r @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. |
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. |
Oh. Apologies for my ignorance. Em, does this mean an mpv-based player could offer those settings in a GUI? |
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). |
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. |
For me cache of 4mb fixed stuttering when playing a file from windows share on OSX |
Btw, in master mpv on OSX will autoenable for files on remote mounts. |
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). |
Any suggestions for a better default cache size? |
Also, how to handle the various cache options:
|
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. |
Doesn't seem to recognise FUSE based mounts on OSX like SSHFS has no cache which causes freezes during playback :( |
@Hackeron Whatever fs type name fuse/sshfs uses on OSX should be added here. I think it would be 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 |
@qmega unfortunately statfs just shows osxfusefs:
|
So which is it? Enabling caching for all fuse filesystems would probably be ok. |
Enabling for all fuse filesystems would be my vote :) |
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. |
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. |
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 :). |
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: |
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. |
In Linux please use BFQ io-scheduler much better soft-realtime latency and 2016-05-05 10:41 GMT-03:00 V. Lang notifications@github.com:
|
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 |
Requested in mpv-player#634. Better late than never?
Requested in #634. Better late than never?
Requested in mpv-player#634. Better late than never?
Would be possible to add support for other BSDs? In this scenario on OpenBSD fstypename is |
I've seen mpv stutter during high disk IO from other tasks, Ubuntu 20.04. |
Came here because video is stuttering for me through macFUSE (https://osxfuse.github.io/). It seems they changed the identifier to "macfuse" now, which is also the name of the package. From calling mount: |
please open a new issue and don't necro a closed issue from 2014, since very likely none will help you like this. |
With mpv 0.36.0 from flatpak build you can't set a number on kilobytes on From |
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).
The text was updated successfully, but these errors were encountered: