summaryrefslogtreecommitdiffstats
path: root/player/video.c
diff options
context:
space:
mode:
authorDudemanguy <random342@airmail.cc>2023-10-29 00:22:02 -0500
committerDudemanguy <random342@airmail.cc>2023-10-30 17:18:35 +0000
commitcb2b579f61764452652c6cf5c6a94ae5e67c77ed (patch)
tree95c925f23e2bb1112bea29fbd508c46d8b952526 /player/video.c
parent1f9d137153a696e42179a836377538535281eef9 (diff)
downloadmpv-cb2b579f61764452652c6cf5c6a94ae5e67c77ed.tar.bz2
mpv-cb2b579f61764452652c6cf5c6a94ae5e67c77ed.tar.xz
player/video: loosen logic checks for adjust_sync
Previously, the av sync change calculation was only done if the audio_status was STATUS_PLAYING, but there is at least one or two more states where this should be done. player/audio is capable of adding delay if the state is anything besides STATUS_EOF. This means that while calling adjust_sync, the delay value could have changed from the audio side of the equation from the previous playloop, and it doesn't necessarily mean that the current audio_status is STATUS_PLAYING either. So the old code would technically skip this case. In practice, this is just one frame so it hardly matters, but it should be taken into account. For example, STATUS_READY is definitely possible here in adjust_sync. I'm not sure if it's actually possible for STATUS_SYNCING to happen but the audio code can change add delay with that status, so it doesn't hurt. STATUS_DRAINING is probably not relevant, but again include it to mirror the audio code logic. Of course, STATUS_EOF is obviously a no-no since that means no audio at all, so we return from there. I didn't take hard measurements or anything, but this does seem to result in slightly smaller av sync fluctuations on discontinuities (like seeking) which makes sense because we're now making an additional correction that wasn't previously done. Another change is to always try adjust_sync as long as the frame_time is nonzero. The old logic only did this if the video_status was playing or greater, but it is possible to get new frames with a different PTS that do not have that status. The audio is still playing so logically it should be adjusted as well. Again, this happens for just one frame, so it doesn't really matter in practice but it should make more sense. A zero frame_time is skipped since that would mean the pts did not advance and the previous playloop should have done the adjustment for that time already.
Diffstat (limited to 'player/video.c')
-rw-r--r--player/video.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/player/video.c b/player/video.c
index b3bd92ca13..e05a0217c1 100644
--- a/player/video.c
+++ b/player/video.c
@@ -342,7 +342,7 @@ static void adjust_sync(struct MPContext *mpctx, double v_pts, double frame_time
{
struct MPOpts *opts = mpctx->opts;
- if (mpctx->audio_status != STATUS_PLAYING)
+ if (mpctx->audio_status == STATUS_EOF)
return;
mpctx->delay -= frame_time;
@@ -387,7 +387,7 @@ static void handle_new_frame(struct MPContext *mpctx)
}
}
mpctx->time_frame += frame_time / mpctx->video_speed;
- if (mpctx->video_status >= STATUS_PLAYING)
+ if (frame_time)
adjust_sync(mpctx, pts, frame_time);
MP_TRACE(mpctx, "frametime=%5.3f\n", frame_time);
}