mirror of
https://github.com/mpv-player/mpv
synced 2025-04-01 14:50:07 +00:00
ca2b10d18d
The demuxer cache benefits slightly from knowing where the current file or stream begins. For example, seeking "left most" when the start is cached would not trigger a low level seek (which would be followed by messy range joining when it notices that the newly demuxed packets overlap with an existing range). Unfortunately, since multimedia is so crazy (or actually FFmpeg in its quite imperfect attempt to be able to demux anything), it's hard to tell where a file starts. There is no feedback whether a specific seek went to the start of the file. Packets are not tagged with a flag indicating they were demuxed from the start position. There is no index available that could be used to cross-check this (even if the file contains a full and "perfect" index, like mp4). You could go by the timestamps, but who says streams start at 0? Streams can start somewhere at an extremely high timestamps (transport streams like to do that), or they could start at negative times (e.g. files with audio pre-padding will do that), and maybe some file formats simply allow negative timestamps and could start at any negative time. Even if the affected file formats don't allow it in theory, they may in practice. In addition, FFmpeg exports a start_time field, which may or may not be useful. (mpv's internal mkv demuxer also exports such a field, but doesn't bother to set it for efficiency and robustness reasons.) Anyway, this is all a huge load of crap, so I decided that if the user performs a seek command to time 0 or earlier, we consider the first packet demuxed from each stream to be at the start of the file. In addition, just trust the start_time field. This is the "shitty" part of this commit. One common case of negative timestamps is audio pre-padding. Demuxers normally behave sanely, and will treat 0 as the start of the file, and the first packets demuxed will have negative timestamps (since they contain data to discard), which doesn't break our assumptions in this commit. (Although, unfortunately, do break some other demuxer cache assumptions, and the first cached range will be shown as starting at a negative time.) Implementation-wise, this is quite simple. Just split the existing initial_state flag into two, since we want to deal with two separate aspects. In addition, this avoids the refresh seek on track switching when it happens right after a seek, instead of only after opening the demuxer. |
||
|---|---|---|
| .. | ||
| 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 | ||