summaryrefslogtreecommitdiffstats
path: root/player/core.h
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2019-10-11 19:34:04 +0200
committerwm4 <wm4@nowhere>2019-10-11 20:01:51 +0200
commitf26dfb6e4d4ecc40c157382f6fcc5a1167334afc (patch)
treed4fba9b1e256c2008551e3d731576f550107143f /player/core.h
parentc84ec021287d72d122071d5c211f9bfbeb13a3fe (diff)
downloadmpv-f26dfb6e4d4ecc40c157382f6fcc5a1167334afc.tar.bz2
mpv-f26dfb6e4d4ecc40c157382f6fcc5a1167334afc.tar.xz
player: partially rework --cache-pause
The --cache-pause feature (enabled by default) will pause playback for a while if network runs out of data. If this is not done, then playback will go on frame-wise (as packets are slowly read from the network and then instantly decoded and displayed). This feature is actually useless, as you won't get nice playback no matter what if network is too slow, but I guess I still prefer this behavior for some reason. This commit changes this behavior from using the demuxer cache state only, to trying to use underrun information from the AO/VO. This means if you have a very large audio buffer, then cache-pausing will trigger once that buffer is depleted, which will be some time _after_ the demuxer cache has run out. This requires explicit support from the AO. Otherwise, the behavior should be mostly the same as before this commit. This does not care about the AO buffer. In theory, the AO may underrun, then the player will write some data to the AO buffer, then the AO will recover and play this bit of data, then the player will probably trigger the cache-pause behavior. The probability of this happening should be pretty low, so I will hold off fixing this until the next refactor of the AO chain (if ever). The VO underflow detection was devised and tested in 5 minutes, and may not be correct. At least I'm fairly sure that the combination of all the factors should make incorrect behavior relatively unlikely, but problems are possible. Also, the demux_reader_state.underrun field may be inaccurate. It's only the present state at the time demux_get_reader_state() was called, and may exclude past underruns. In theory, this could cause "close" cases to be missed. Then you might get an audio underrun without cache-pausing acting on it. If the stars align, this could happen multiple times in the row, effectively making this feature not work. The most user-visible consequence of this change is that the user will now see an AO underrun warning every time the cache runs out. Maybe this cache-pause feature should just be removed...
Diffstat (limited to 'player/core.h')
-rw-r--r--player/core.h5
1 files changed, 5 insertions, 0 deletions
diff --git a/player/core.h b/player/core.h
index 11e741bb78..0edf4fa31e 100644
--- a/player/core.h
+++ b/player/core.h
@@ -183,6 +183,8 @@ struct vo_chain {
bool is_coverart;
// - video consists of sparse still images
bool is_sparse;
+
+ bool underrun;
};
// Like vo_chain, for audio.
@@ -206,6 +208,8 @@ struct ao_chain {
struct track *track;
struct mp_pin *filter_src;
struct mp_pin *dec_src;
+
+ bool underrun;
};
/* Note that playback can be paused, stopped, etc. at any time. While paused,
@@ -423,6 +427,7 @@ typedef struct MPContext {
bool playing_msg_shown;
bool paused_for_cache;
+ bool demux_underrun;
double cache_stop_time;
int cache_buffer;