demux, demux_mkv: fix seeking in cache with large codec delay

In this scenario, the demuxer will output timestamps offset by the codec
delay (e.g. negative timestamps at the start; mkv simulates those), and
the trimming in the decoder (often libavcodec, but ad_lavc.c in our
case) will adjust the timestamps back (e.g. stream actually starts at
0).

This offset needs to be taken into account when seeking. This worked in
the uncached case. (demux_mkv.c is a bit tricky in that the index is
already in the offset space, so it compensates even though the seek call
does not reference codec_delay.) But in the cached case, seeks backwards
did not seek enough, and forward they seeked too much.

Fix this by adding the codec delay to the index search. We need to get
"earlier" packets, so e.g. seeking to position 0 really gets the initial
packets with negative timestamps.

This also adjusts the seek range start. This is also pretty obvious: if
the beginning of the file is cached, the seek range should start at 0,
not a negative value. We compare 0-based timestamps to it later on.

Not sure if this is the best approach. I also could have thought
about/checked some corner cases harder. But fuck this shit.

Not fixing duration (who cares) or end trimming, which would reduce the
seek range and duration (who cares).

1 files changed, 2 insertions, 0 deletions

diff --git a/demux/stheader.h b/demux/stheader.h
index beca0fabf7..198f16cd49 100644
--- a/demux/stheader.h
+++ b/demux/stheader.h
@@ -55,6 +55,8 @@ struct sh_stream {
 
     bool missing_timestamps;
 
+    double seek_preroll;
+
     // stream is a picture (such as album art)
     struct demux_packet *attached_picture;