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.)
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.
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.
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).
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.
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.
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.
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.
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.
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.
This refactor makes the code easier to understand. Also corrects a bug that
caused the window to move to the left when the new size was bigger than the
visible frame.
I am aware this detection may occur too late, depending on other
settings, but at least it usually works and is portable.
Where the output fd can be changed, though, it'd be better to force a
similar behaviour via file descriptor use: use pipe:3 as output to FD 3,
and change the calling program to expect the stream on FD 3.
These require bleeding edge libass (latest git version), and will be
ignored otherwise.
I'm not sure about the blur factor and scaling. The ASS/VSFilter
semantics for blur scaling are a bad mess. Might require further
investigation.
The condition that checked whether the chapters are out of order and
should be sorted was inverted. This likely wasn't noticed in testing,
because even if the chapters are unsorted, if the last two chapters
were sorted, the rest got sorted too.
Instead of doing this silly check, always sort the chapters after
demuxer initialization. Also make sure the sort order is stable in case
chapter start times are the same (original_index check).
This option can be used to selectively reset settings when playing the
next file in the playlist (i.e. restore mplayer and mplayer2 behavior).
Might remove this option again should it turn out that nobody uses it.
Consider:
mpv --volume 10 file1.mkv file2.mkv
Before this commit, the volume was reset to 10 when playing file2.mkv.
This was inconsistent to most other options. E.g. --brightness is a
rather similar case.
In general, settings should never be reset when playing the next file,
unless the option was explicitly marked file-local. This commit
corrects the behavior of the --volume and --mute options.
File local --volume still works as expected:
mpv --{ --volume 10 file1.mkv file2.mkv --}
This sets the volume always to 10 on playback start.
Move the m_config_leave_file_local() call down so that the mixer code
in uninit_player() can set the option volume and mute variables without
overwriting the global option values.
Another subtle issue is that we don't want to set volume if there's no
need to, which is why the user_set_volume/mute fields are introduced.
This is important because setting the volume might change the system
volume depending on other options.
At least libsdl adds -mwindows to the cflags, which marks the .exe
binary as GUI application. This means the program detaches from the
console when started in cmd.exe, instead of showing the playback
status, receiving console input, and so on.
Append -mconsole to the linker command line to disable -mwindows.
CC demux/demux.o
demux/demux.c: In function 'demuxer_switch_track':
demux/demux.c:1241:29: warning: array subscript is above array bounds [-Warray-bounds]
int new_id = demuxer->ds[type]->id;
^
Commit bc20f2c moved the variable default_max_pts_correction (which
backs the --mc option) to the MPOpts struct. The initializer was
forgotten when doing this, so it was left at 0. This disabled part of
the A/V sync mechanism. This was apparent when using ad_spdif (this
decoder has other A/V sync related problems, and thus triggers this
issue easily).
Closes#59.
ntddcdrm.h is no longer under the 'ddk' directory in MinGW-w64,
and since MPV focuses on it instead of the old MinGW32, there's no
reason to keep that dir prefix, as it stops VCD support from being
built at all for Windows.
