From 340deb4e6eb1cf09c19cef5bd19c7eab51d6862b Mon Sep 17 00:00:00 2001 From: wm4 Date: Fri, 29 Jan 2016 22:43:59 +0100 Subject: player: fix initial audio sync in certain cases Regression caused by commit 3b95dd47. Also see commit 4c25b000. We can either use video_next_pts and add "delay", or we just use video_pts. Any other combination breaks. The reason why the assumption that delay==0 at this point was wrong exactly because after displaying the first video frame (usually done before audio resync) a new frame might be "added" immediately, resulting in a new video_next_pts and "delay", which will still amount to video_pts. Fixes #2770. (The reason why display-sync was blamed in this issue is because enabling display-sync in the options forces a prefetch by 2 instead of 1 frames for seeks/playback restart, which triggers the issue, even if display-sync is not actually enabled. In this case, display-sync is never enabled because the frames have a unusually high frame duration. This is also what exposed the initial desync issue.) --- player/core.h | 2 -- 1 file changed, 2 deletions(-) (limited to 'player/core.h') diff --git a/player/core.h b/player/core.h index 879470724e..7d34380e87 100644 --- a/player/core.h +++ b/player/core.h @@ -351,8 +351,6 @@ typedef struct MPContext { * (or at least queued to be flipped by VO) */ double video_pts; double last_seek_pts; - // Mostly unused; for proper audio resync on speed changes. - double video_next_pts; // As video_pts, but is not reset when seeking away. (For the very short // period of time until a new frame is decoded and shown.) double last_vo_pts; -- cgit v1.2.3