diff options
author | wm4 <wm4@nowhere> | 2013-05-23 00:26:42 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2013-05-23 01:02:24 +0200 |
commit | 5bdf9d01cafd451fa971e94d5f2dab982338130a (patch) | |
tree | e5eb194723ff50925c6dd1fe8b6dde65cf3f0917 /DOCS/man | |
parent | 1139eae082b30e1230c1b882ddd472bfadd37e32 (diff) | |
download | mpv-5bdf9d01cafd451fa971e94d5f2dab982338130a.tar.bz2 mpv-5bdf9d01cafd451fa971e94d5f2dab982338130a.tar.xz |
demux_mkv: defer reading of seek index until first seek
Playing Youtube videos often requires an additional seek to the end of
the file. This flushes the stream cache. The reason for the seek is
reading the cues (seek index). This poses the question why Google is
muxing its files in such a way, since nothing in Matroska mandates that
cues are located at the end of the file, but we want to handle this
situation better anyway.
The seek index is not needed for normal playback, only for seeking.
This commit changes header parsing such that the index is not read on
initialization in order to avoid the additional stream-level seek.
Instead, read the index on the first demuxer-level seek, when the seek
index is actually needed.
If the cues are at the beginning of the file, they are read immediately
as part of the normal header reading process. This commit changes
behavior only if cues are outside of the header (i.e. not in the area
between EBML header and clusters), and linked by a SeekHead. Other
level 1 elements linked by the SeekHead might still cause seeks to the
end of the file, although that seems to be rare.
Diffstat (limited to 'DOCS/man')
0 files changed, 0 insertions, 0 deletions