path: root/player/audio.c
diff options
authorwm4 <wm4@nowhere>2014-08-22 15:28:05 +0200
committerwm4 <wm4@nowhere>2014-08-22 15:36:48 +0200
commit4c25b000b5e521c67608284cf23972e2f651e9d3 (patch)
tree6c46376827fb68320777f7529855141e8699b1aa /player/audio.c
parent75005ec06d13655340439450cd4663bdf7978411 (diff)
player: fix recent speed change regression
Commit 5afc025c broke this. The reason is that mpctx->delay is updated when a new video frame is added. This value is also needed to resync audio, but it will be for the wrong PTS. They must be consistent with each other, and if they aren't, initial sync will be off by N video frames, which results at least in worse user experience. This can be reproduced by for example heavily switching between normal and 2x speed, or similar. Fix by readding the video_next_pts field (keeping its use minimal, instead of reverting the commit that removed it).
Diffstat (limited to 'player/audio.c')
1 files changed, 2 insertions, 2 deletions
diff --git a/player/audio.c b/player/audio.c
index df80fcd161..3a691fed09 100644
--- a/player/audio.c
+++ b/player/audio.c
@@ -329,8 +329,8 @@ static bool get_sync_samples(struct MPContext *mpctx, int *skip)
double sync_pts = MP_NOPTS_VALUE;
if (sync_to_video) {
- if (mpctx->video_pts != MP_NOPTS_VALUE) {
- sync_pts = mpctx->video_pts;
+ if (mpctx->video_next_pts != MP_NOPTS_VALUE) {
+ sync_pts = mpctx->video_next_pts;
} else if (mpctx->video_status < STATUS_READY) {
return false; // wait until we know a video PTS