mirror of
https://github.com/mpv-player/mpv
synced 2025-01-05 22:49:58 +00:00
01423d8c03
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). |
||
|---|---|---|
| .. | ||
| codec_tags.c | ||
| codec_tags.h | ||
| cue.c | ||
| cue.h | ||
| demux_cue.c | ||
| demux_edl.c | ||
| demux_lavf.c | ||
| demux_libarchive.c | ||
| demux_mf.c | ||
| demux_mkv_timeline.c | ||
| demux_mkv.c | ||
| demux_null.c | ||
| demux_playlist.c | ||
| demux_raw.c | ||
| demux_timeline.c | ||
| demux.c | ||
| demux.h | ||
| ebml.c | ||
| ebml.h | ||
| matroska.h | ||
| packet.c | ||
| packet.h | ||
| stheader.h | ||
| timeline.c | ||
| timeline.h | ||