summaryrefslogtreecommitdiffstats
path: root/player/video.c
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/video.c
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/video.c')
-rw-r--r--player/video.c8
1 files changed, 7 insertions, 1 deletions
diff --git a/player/video.c b/player/video.c
index 1d800a96d3..680636b075 100644
--- a/player/video.c
+++ b/player/video.c
@@ -91,6 +91,7 @@ int reinit_video_filters(struct MPContext *mpctx)
static void vo_chain_reset_state(struct vo_chain *vo_c)
{
vo_seek_reset(vo_c->vo);
+ vo_c->underrun = false;
}
void reset_video_state(struct MPContext *mpctx)
@@ -1003,8 +1004,13 @@ void write_video(struct MPContext *mpctx)
if (r < 0)
goto error;
- if (r == VD_WAIT) // Demuxer will wake us up for more packets to decode.
+ if (r == VD_WAIT) {
+ // Heuristic to detect underruns.
+ if (mpctx->video_status == STATUS_PLAYING && !vo_still_displaying(vo))
+ vo_c->underrun = true;
+ // Demuxer will wake us up for more packets to decode.
return;
+ }
if (r == VD_EOF) {
if (check_for_hwdec_fallback(mpctx))