summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2019-11-16 13:47:23 +0100
committerwm4 <wm4@nowhere>2019-11-16 13:47:23 +0100
commit6bbf44d842090b6d34b8893e575b7fa7cbc14b13 (patch)
treece694d3b897ccb8eaaa94441ef01b708d09f4ce9
parentb6413f82b22b5c3bd7b0a4fec28fdd2625feaf94 (diff)
downloadmpv-6bbf44d842090b6d34b8893e575b7fa7cbc14b13.tar.bz2
mpv-6bbf44d842090b6d34b8893e575b7fa7cbc14b13.tar.xz
video: take first frame into account in audio-sync mode
It appears commit 4ad68d94523c3d101a broke handling the first video frame duration through roundabout ways (I think because the duration of the first frame was now available at all in the normal case). The first frame was cut short, which showed up especially with looping, or if the file had a low FPS. This questionable change seems to fix it without breaking any other known cases => push and call it a day. The display-sync mode did not have this problem. Fixes: #7150
-rw-r--r--player/video.c5
1 files changed, 2 insertions, 3 deletions
diff --git a/player/video.c b/player/video.c
index 7e24502e8c..1a3cfb3b5f 100644
--- a/player/video.c
+++ b/player/video.c
@@ -384,10 +384,9 @@ static void handle_new_frame(struct MPContext *mpctx)
}
}
mpctx->delay -= frame_time;
- if (mpctx->video_status >= STATUS_PLAYING) {
- mpctx->time_frame += frame_time / mpctx->video_speed;
+ mpctx->time_frame += frame_time / mpctx->video_speed;
+ if (mpctx->video_status >= STATUS_PLAYING)
adjust_sync(mpctx, pts, frame_time);
- }
MP_TRACE(mpctx, "frametime=%5.3f\n", frame_time);
}