summaryrefslogtreecommitdiffstats
path: root/player/command.c
diff options
context:
space:
mode:
authorDudemanguy <random342@airmail.cc>2024-02-25 16:26:30 -0600
committerDudemanguy <random342@airmail.cc>2024-02-26 15:41:34 +0000
commite3af545421322e357eb9355395923710ea93f83b (patch)
treec7c121d7a51da5c01580ed1e653ca5fae6f34dbf /player/command.c
parent7051e94e4bacd00e53e88835d28e9d9082de3bb3 (diff)
downloadmpv-e3af545421322e357eb9355395923710ea93f83b.tar.bz2
mpv-e3af545421322e357eb9355395923710ea93f83b.tar.xz
player: reset av state on speed changes
Playback speed changes should be treated as a discontinuity just like seeking. Previously, this was being treated internally as just plain normal playback, but that can't really work. The frame timings from before the speed change and after the speed change are completely different and shouldn't be compared to each other. This lead to frames being adjusted to weird places and possibly even being skipped (as if mpv was seeking) on speed changes. What we should do is clear out and reset all av related fields like what happens when you seek, but it is not quite as aggressive. No need to do a full video state reset or such. We also wait an arbitrary amount of frames before adjusting for av sync again. compute_audio_drift already used a magic number of 10 which sounds reasonable enough so define that and use it here. Fixes #13513.
Diffstat (limited to 'player/command.c')
-rw-r--r--player/command.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/player/command.c b/player/command.c
index d5a315290e..f8fac69ef7 100644
--- a/player/command.c
+++ b/player/command.c
@@ -7228,6 +7228,7 @@ void mp_option_change_callback(void *ctx, struct m_config_option *co, int flags,
if (opt_ptr == &opts->playback_speed) {
update_playback_speed(mpctx);
+ reset_av_state(mpctx);
mp_wakeup_core(mpctx);
}