The dark mode is only turned on if Windows 10's own dark mode is
enabled. This manual dark mode configuration is necessary as Qt itself
doesn't support Windows' dark mode yet; see the following bug:
https://bugreports.qt.io/browse/QTBUG-72028
This isn't a problem for other operating systems (Linux, macOS…) as Qt
uses the system colors there and will use dark colors when the
system's colors are set to dark colors, too.
The original AppRun contains a hard-coded change to the current
working directory to the mounted installation. This made using
relative file names impossible. However, the MKVToolNix can be run
from anywhere and don't rely on the current working directory.
Fixes#2632.
Features include debuging, profiling, optimizations & sanitizers. The
flags don't depend on something that's actually tested, but only on
which features are enabled and which compiler & compiler version is
used. Therefore doing it in Ruby instead of sh is easier.
Before the file probing code opened the file once, did its thing, and
closed the file again. No information from that stage was available to
the header reading stage. This meant that headers had to be parsed
twice for several formats. The probing function was a static member
function, making passing information to the header reading function,
which was an instance member function, even more difficult.
After refactoring the file is only opened once. The same open file
handle is used by both the probing & the header reading
functions. Both of those functions are now instance member functions,
and the same object instance is used for both calls, allowing passing
information from the probing to the header reading stage.
Additionally this enabled the removal of a lot of boilerplate code
such as passing variables to the various probing functions or handling
exceptions in each probing function instead of in the function calling
the probes. The git diff stats confirm this rather impressively:
78 files changed, 769 insertions(+), 1778 deletions(-)
A net gain of more than 1000 lines.
There are files that start with garbage, and where that garbage
contains data that forms valid ADTS or LATM headers. In that case the
file type detection might detect the valid data (more than e.g. eight
consecutive valid headers of the same type with the same parameters)
starting at an offset, e.g. at position 100.000.
However, the code reading the file headers later on only looked for
the first header that passed validation, which might mean a header at
a much earlier position in the file — which only looks like a valid
header by accident. The result was wrong codec parameters.
Fixes#2622.
