summaryrefslogtreecommitdiffstats
path: root/player/playloop.c
diff options
context:
space:
mode:
authorAman Gupta <aman@tmm1.net>2016-10-20 11:43:17 -0700
committerwm4 <wm4@nowhere>2016-10-21 17:11:26 +0200
commit8b00d82b79393d0c09b1084c913e4067b9d8eaf5 (patch)
tree672ad25ae2a8866d66d521d7b813daf074f19410 /player/playloop.c
parent7cd32ec29e9641362f4a14e4e1284040f9af9930 (diff)
downloadmpv-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.
Diffstat (limited to 'player/playloop.c')
-rw-r--r--player/playloop.c2
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;