gcc 4.9.2 on Debian Jessie doesn't like using brace-initialization
that deep, it seems. Error message was:
> src/input/unsupported_types_signature_prober.cpp:66:3: error: no
> matching function for call to
> ‘std::vector<{anonymous}::signature_t>::vector(<brace-enclosed
> initializer list>)’
This prevents mis-detection by the more lenient reader modules,
especially the MPEG-2 ES reader. It would consider the WTV structural
bytes being part of the MPEG-2 frames.
Fixes#2347.
Back in the day the Matroska reader was only trying to shift
timestamps to 0 by using the first cluster's cluster timestamp. Quite
a while later real zeroing was implemented by actually reading the
timestamps of all blocks of the first ~20 MB of the file or so, but
the original method wasn't removed.
This was bad in two ways:
1. The older method was wrong as the first cluster's timestamp didn't
have to be equal to the lowest timestamp in the file as block
timestamps can be negative.
2. There were two methods for downshifting that were applied on top of
each other when appending.
This removes the old, wrong way.
Fixes#2345.
Before progress was measured in number of elements (frames/blocks) to
process for those readers that could provide that information without
processing the whole file (e.g. MP4, AVI). As those elements could
have wildly varying sizes, each reader's `get_progress()` function
returned its progres as a number in the range `[0..100]`.
This meant, though, that the effort/time required to reach 100% could
not be gauged from outside the reader. In situations such as appending
files, mkvmerge's core had to guess which readers to use for
progress. It did so looking for the longest chain of appended files
and using its readers and their progress reports.
This is obviously wrong even for simple cases: e.g. you have a single,
huge M2TS and two text subtitle files. You append the two subtitle
files and add the M2TS. The time for muxing was clearly dominated by
the M2TS — but the progress was reported according to the tiny text
subtitle files.
After the rewrite the total progress is simply the total number of
bytes of all source files. The current progress is roughly the sum of
the number of bytes that have been processed for each source file.
Fixes#2150 and #2330.
