summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2019-09-24 19:06:59 +0200
committerwm4 <wm4@nowhere>2019-09-24 19:06:59 +0200
commit68ce36a2db562e3ea9cbc8f23084c5b9c7ed64e5 (patch)
tree8c23d41f7fbf0e30148c10a4e8677e0ad2e0acab
parentd2a9e3fb341694fa0d202b86fe57d677d3b3b609 (diff)
downloadmpv-68ce36a2db562e3ea9cbc8f23084c5b9c7ed64e5.tar.bz2
mpv-68ce36a2db562e3ea9cbc8f23084c5b9c7ed64e5.tar.xz
demux: force reading packets again after seeks
in->eof is used as an indicator whether reading packets still makes sense. (Without this, the prefetcher would obviously burn CPU by retrying reading even though everything has been read.) This was not reset properly after seeks were performed. It led to getting stuck in at least one corner case: when enabling a track, the demuxer would seek backwards to get new packets from the current playback position ("refresh seeks"). But if playback was paused, and EOF was previously reached, it would not try to read packers again due to in->eof being false. There was not anything else that would make it retry reading, so it was stuck in a weird underrun/buffering state. Fixes: #6986
-rw-r--r--demux/demux.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/demux/demux.c b/demux/demux.c
index d5000d5355..277bccb2a6 100644
--- a/demux/demux.c
+++ b/demux/demux.c
@@ -2347,7 +2347,7 @@ static void execute_seek(struct demux_internal *in)
{
int flags = in->seek_flags;
double pts = in->seek_pts;
- in->last_eof = false;
+ in->last_eof = in->eof = false;
in->seeking = false;
in->seeking_in_progress = pts;
in->demux_ts = MP_NOPTS_VALUE;