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.)

1 files changed, 0 insertions, 2 deletions

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;