summaryrefslogtreecommitdiffstats
path: root/player/core.h
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2018-01-03 21:28:28 +0100
committerKevin Mitchell <kevmitch@gmail.com>2018-01-03 15:43:51 -0800
commit9c22108fec447183a85f8775e92d7c19ea251d75 (patch)
tree2b90fa6d3635ef294e2c29bcd190e928616a80f1 /player/core.h
parent6092c967abfcd864567d518c1d8305000a086aed (diff)
downloadmpv-9c22108fec447183a85f8775e92d7c19ea251d75.tar.bz2
mpv-9c22108fec447183a85f8775e92d7c19ea251d75.tar.xz
player: use fixed timeout for cache pausing (buffering) duration
This tried to be clever by waiting for a longer time each time the buffer was underrunning, or shorter if it was getting better. I think this was pretty weird behavior and makes no sense. If the user really wants the stream to buffer longer, he/she/it can just pause the player (the network caches will continue to be filled until they're full). Every time I actually noticed this code triggering in my own use, I didn't find it helpful. Apart from that it was pretty hard to test. Some waiting is needed to avoid that the player just plays the available data as fast as possible (to compensate for late frames and underrunning audio). Just use a fixed wait time, which can now be controlled by the new --cache-pause-wait option.
Diffstat (limited to 'player/core.h')
-rw-r--r--player/core.h2
1 files changed, 1 insertions, 1 deletions
diff --git a/player/core.h b/player/core.h
index 4f4765d3e5..cee1bf3bc2 100644
--- a/player/core.h
+++ b/player/core.h
@@ -432,7 +432,7 @@ typedef struct MPContext {
bool playing_msg_shown;
bool paused_for_cache;
- double cache_stop_time, cache_wait_time;
+ double cache_stop_time;
int cache_buffer;
// Set after showing warning about decoding being too slow for realtime