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, 2 insertions, 2 deletions

diff --git a/player/audio.c b/player/audio.c
index 47acffb8b7..ddf32fb277 100644
--- a/player/audio.c
+++ b/player/audio.c
@@ -512,8 +512,8 @@ static bool get_sync_samples(struct MPContext *mpctx, int *skip)
     if (sync_to_video) {
         if (mpctx->video_status < STATUS_READY)
             return false; // wait until we know a video PTS
-        if (mpctx->video_next_pts != MP_NOPTS_VALUE)
-            sync_pts = mpctx->video_next_pts - opts->audio_delay;
+        if (mpctx->video_pts != MP_NOPTS_VALUE)
+            sync_pts = mpctx->video_pts - opts->audio_delay;
     } else if (mpctx->hrseek_active) {
         sync_pts = mpctx->hrseek_pts;
     }