From 8b00d82b79393d0c09b1084c913e4067b9d8eaf5 Mon Sep 17 00:00:00 2001 From: Aman Gupta Date: Thu, 20 Oct 2016 11:43:17 -0700 Subject: 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. --- player/playloop.c | 2 ++ 1 file changed, 2 insertions(+) (limited to 'player/playloop.c') 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; -- cgit v1.2.3