diff options
author | wm4 <wm4@nowhere> | 2019-11-16 13:47:23 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2019-11-16 13:47:23 +0100 |
commit | 6bbf44d842090b6d34b8893e575b7fa7cbc14b13 (patch) | |
tree | ce694d3b897ccb8eaaa94441ef01b708d09f4ce9 | |
parent | b6413f82b22b5c3bd7b0a4fec28fdd2625feaf94 (diff) | |
download | mpv-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.c | 5 |
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); } |