summaryrefslogtreecommitdiffstats
path: root/player/core.h
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/core.h
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/core.h')
-rw-r--r--player/core.h4
1 files changed, 4 insertions, 0 deletions
diff --git a/player/core.h b/player/core.h
index 1dc6da7331..70570fccb3 100644
--- a/player/core.h
+++ b/player/core.h
@@ -382,6 +382,10 @@ typedef struct MPContext {
bool immediate; // disable seek delay logic
} seek;
+ // Allow audio to issue a second seek if audio is too far ahead (for non-hr
+ // seeks with external audio tracks).
+ bool audio_allow_second_chance_seek;
+
/* Heuristic for relative chapter seeks: keep track which chapter
* the user wanted to go to, even if we aren't exactly within the
* boundaries of that chapter due to an inaccurate seek. */