diff options
| author | Aman Gupta <aman@tmm1.net> | 2016-10-20 11:43:17 -0700 |
|---|---|---|
| committer | wm4 <wm4@nowhere> | 2016-10-21 17:11:26 +0200 |
| commit | 8b00d82b79393d0c09b1084c913e4067b9d8eaf5 (patch) | |
| tree | 672ad25ae2a8866d66d521d7b813daf074f19410 | |
| parent | 7cd32ec29e9641362f4a14e4e1284040f9af9930 (diff) | |
| download | mpv-8b00d82b79393d0c09b1084c913e4067b9d8eaf5.tar.bz2 mpv-8b00d82b79393d0c09b1084c913e4067b9d8eaf5.tar.xz | |
player: guard against MPSEEK_RELATIVE when current pts is unknown
in very rare circumstances, doing a relative seek like +1s will end up
doing an absolute seek to 00:01. this guards against that possibility.
so far i've only ever seen this issue when using --ad=lavc:ac3_at and
doing several relative seeks in quick succession. this is likely either
a bug in the audiotoolbox decoder in ffmpeg, or simply due to inherent
latency in that hardware decoder which causes brief periods of time
where the current audio pts is unknown.
| -rw-r--r-- | player/playloop.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/player/playloop.c b/player/playloop.c index 18a51f33d0..934b8ff0d9 100644 --- a/player/playloop.c +++ b/player/playloop.c @@ -249,6 +249,8 @@ static void mp_seek(MPContext *mpctx, struct seek_params seek) bool hr_seek_very_exact = seek.exact == MPSEEK_VERY_EXACT; double current_time = get_current_time(mpctx); + if (current_time == MP_NOPTS_VALUE && seek.type == MPSEEK_RELATIVE) + return; if (current_time == MP_NOPTS_VALUE) current_time = 0; double seek_pts = MP_NOPTS_VALUE; |