manpage: clarify --cache behavior
demux_mkv: use normal index data structure even for incomplete files

Incomplete files don't have a valid index, because the index is usually
located near the end of a file. In this case, an index is created on the
fly during demuxing, or when seeks are done.

This used a completely different code path, which leads to unnecessary
complications and code duplication. Use the normal index data structure
instead. The seeking code at the end of seek_creating_index() (in this
commit renamed to create_index_until()) is removed. The normal seek code
does the same thing instead.
demux_mkv: simplify cluster reading code

The end positions of the current cluster and block were managed by
tracking their size and how much of them were read, instead of just
using the absolute end positions.

I'm not sure about the reasons why this code was originally written
this way. One obvious concern is reading from pipes and such, but the
stream layers hides this. stream_tell(s) works even when reading from
pipes. It's also a fast call, and doesn't involve the stream
implementation or syscalls. Keeping track of the cluster/block end is
simpler and there's no reason why this wouldn't work.
demux_mkv: fix streaming clusters

Matroska files prepared for streaming have clusters with unknown size.
These files are pretty rare, see e.g. test4.mkv from the official
Matroska test file collection.
demux_mkv: factor block reading

The code for reading block data was duplicated. Move it into a function.

Instead of returning on error (possibly due to corrupt data) and
signalling EOF, continue by trying to find the next block. This makes
error handling slightly simpler too, because you don't have to care
about freeing the current block. We could still signal EOF in this case,
but trying to resync sounds better for dealing with corrupted files.
demux_mkv: move BlockGroup reading code to a separate function

Somehow this was setup such that a BlockGroup can be incrementally
read (at least in theory). This makes no sense, as BlockGroup can
contain only one Block (despite its name). There's no need to read
this incrementally, and makes the code confusing for no gain.

Read all the BlockGroup sub-elements with a single function call,
without keeping global state for BlockGroup parsing.
demux_mkv: split reading blocks and reading packets

Move most code from demux_mkv_fill_buffer() to read_next_block(). The
former is supposed to read raw blocks, while ..fill_buffer() reads
blocks and turns them into packets.
demux_mkv: move Block header parsing code

Move parts of the Block element parsing to read_block(). This way
read_block() can return block time and track information in
struct block_info.
demux_mkv: fix seeking with index generation

Relative seeks backwards didn't work too well with incomplete files, or
other files that are missing the seek index. The problem was that the
on-the-fly seek index generation simply added cluster positions as seek
entries. While this is perfectly fine, the seek code had no information
about the location of video key frames. For example, a 5 second long
cluster can have only 1 video key frame, which is located 4 seconds into
the cluster. Seeking backwards by one second while still located in the
same cluster would select this cluster as seek target again. Decoding
would resume with the key frame, giving the impression that seeking is
"stuck" at this frame.

Make the generated index aware of key frame and track information, so
that video can always be seeked in an idea way. This also uses the
normal block parsing code for indexing the clusters, instead of the
suspicious looking special code. (This code didn't parse the Matroska
elements correctly, but was fine for files with normal structure. Files
with corrupted clusters or clusters formatted for streaming were not
handled properly.)

Skipping is now quite a bit slower (takes about twice as long as
before), but it removes the special cased skipping code, and it's still
much faster (at least twice as fast) than libavformat. It needs to do
more I/O (no more skipping entire clusters, all data is read), and has
more CPU usage (more data needs to be parsed).
demux_mkv: remove redundant check
demux_mkv: static allocation for lace sizes buffer

Avoid messy memory management and error handling.

remove tmp_lace_buffer non-sense

Not sure how my mind got 8k, or how this made sense at all.
demux_mkv: use a bounded buffer for block data

Should help avoiding out-of-bounds reads.
demux_mkv: check block malloc() result
demux_mkv: there can be 256 laces

The lace number is stored with an offset of 1, so the maximum number
of laces is 255+1=256.
demux_mkv: get rid of the duplicated lace case labels

Also change the extracting of the lace type bitfield from flags to
make it more apparent that the value range is 0-3.
demux_mkv: verify laces separately, and in all cases
demux_mkv: simplify handle_block() logic a bit
mplayer: take tracks from first segment if main file is empty

With Matroska ordered chapters, the main file (i.e. the file you're
playing) can be empty, while all video/audio data is in linked files.
Some files don't even contain the track list, only chapter information.
mpv refused to play these, because normally, the main file dictates the
track layout.

Fix this by using the first segment for track data if no part of the
timeline is sourced from the main file.
demux_mkv: don't terminate if there are no clusters

Matroska segment linking allows abusing Matroska files as playlists
without any actual video/audio/sub data, making files without any
clusters still useful for the frontend.
core: matroska: support concatenated segments

Matroska files can contain multiple segments, which are literally
further Matroska files appended to the main file. They can be referenced
by segment linking.

While this is an extraordinarily useless and dumb feature, we support it
for the hell of it.

This is implemented by adding a further demuxer parameter for skipping
segments. When scanning for linked segments, each file is opened
multiple times, until there are no further segments found. Each segment
will have a separate demuxer instance (with a separate file handle
etc.).

It appears the Matroska spec. has an even worse feature for segments:
live streaming can completely reconfigure the stream by starting a new
segment. We won't add support for it, because there are 0 people on this
earth who think Matroska life streaming is a good idea. (As opposed to
serving Matroska/WebM files via HTTP.)