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 /player | |
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.
Diffstat (limited to 'player')
-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; |