player: redo hack for video keyframe seeks with external audio

If you play a video with an external audio track, and do backwards
keyframe seeks, then audio can be missing. This is because a backwards
seek can end up way before the seek target (this is just how this seek
mode works). The audio file will be seeked at the correct seek target
(since audio usually has a much higher seek granularity), which results
in silence being played until the video reaches the originally intended
seek target.

There was a hack in audio.c to deal with this. Replace it with a
different hack. The new hack probably works about as well as the old
hack, except it doesn't add weird crap to the audio resync path (which
is some of the worst code here, so this is some nice preparation for
rewriting it). As a more practical advantage, it doesn't discard the
audio demuxer packet cache. The old code did, which probably ruined
seeking in youtube DASH streams.

A non-hacky solution would be handling external files in the demuxer
layer. Then chaining the seeks would be pretty easy. But we're pretty
far from that, because it would either require intrusive changes to the
demuxer layer, or wouldn't be flexible enough to load/unload external
files at runtime. Maybe later.

1 files changed, 3 insertions, 3 deletions

diff --git a/player/core.h b/player/core.h
index 041065e1f6..f2fed55366 100644
--- a/player/core.h
+++ b/player/core.h
@@ -412,9 +412,9 @@ typedef struct MPContext {
 
     struct seek_params 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;
+    // Can be temporarily set to an external audio track after seeks. Then it
+    // must be seeked to the video position once video is done seeking.
+    struct track *seek_slave;
 
     /* Heuristic for relative chapter seeks: keep track which chapter
      * the user wanted to go to, even if we aren't exactly within the