summaryrefslogtreecommitdiffstats
path: root/player/playloop.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2016-08-07 16:29:13 +0200
committerwm4 <wm4@nowhere>2016-08-07 16:29:13 +0200
commit259f2194385e86e47eb054d43f155ca897e265c6 (patch)
tree9f9e0446ffb24305849956d1404eaf7d2bd123db /player/playloop.c
parentc7b73edc652785885163879bda3981a3d43cd466 (diff)
downloadmpv-259f2194385e86e47eb054d43f155ca897e265c6.tar.bz2
mpv-259f2194385e86e47eb054d43f155ca897e265c6.tar.xz
player: gross hack to improve non-hr seeking with external audio tracks
Relative seeks backwards with external audio tracks does not always work well: it tends to happen that video seek back further than audio, so audio will remain silent until the audio's after-seek position is reached. This happens because we strictly seek both video and audio demuxer to the approximate desirted target PTS, and then start decoding from that. Commit 81358380 removes an older method that was supposed to deal with this. It was sort of bad, because it could lead to the playback core freezing by waiting on network. Ideally, the demuxer layer would probably somehow deal with such seeks, and do them in a way the audio is seeked after video. Currently this is infeasible, because the demuxer layer assumes a single demuxer, and external tracks simply use separate demuxer layers. (MPlayer actually had a pseudo-demuxer that joined external tracks into a single demuxer, but this is not flexible enough - and also, the demuxer layer as it currently exists can't deal with dynamically removing external tracks either. Maybe some time in the future.) Instead, add a gross hack, that essentially reseeks the audio if it detects that it's too far off. The result is actually not too bad, because we can reuse the mechanism that is used for instant track switching. This way we can make sure of the right position, without having to care about certain other issues. It should be noted that if the audio demuxer is used for other tracks too, and the demuxer does not support refresh seeking, audio will probably be off by even a higher amount. But this should be rare.
Diffstat (limited to 'player/playloop.c')
-rw-r--r--player/playloop.c4
1 files changed, 4 insertions, 0 deletions
diff --git a/player/playloop.c b/player/playloop.c
index da3e995975..9b15ac3f50 100644
--- a/player/playloop.c
+++ b/player/playloop.c
@@ -298,6 +298,9 @@ static void mp_seek(MPContext *mpctx, struct seek_params seek)
mp_notify(mpctx, MPV_EVENT_SEEK, NULL);
mp_notify(mpctx, MPV_EVENT_TICK, NULL);
+
+ mpctx->audio_allow_second_chance_seek =
+ !hr_seek && !(demux_flags & SEEK_FORWARD);
}
// This combines consecutive seek requests.
@@ -889,6 +892,7 @@ static void handle_playback_restart(struct MPContext *mpctx)
if (!mpctx->restart_complete) {
mpctx->hrseek_active = false;
mpctx->restart_complete = true;
+ mpctx->audio_allow_second_chance_seek = false;
mp_notify(mpctx, MPV_EVENT_PLAYBACK_RESTART, NULL);
if (!mpctx->playing_msg_shown) {
if (opts->playing_msg && opts->playing_msg[0]) {