QStrings can be null in addition to being empty. A NULL string converts
to a null QVariant, which in turn converts to null JSON object. mkvmerge
expects strings, though.
One way to trigger this is:
• Disable the option "automatically set the file title from source
files" in the GUI's preferences
• Add a file that contains a title
• Don't touch the "file title" input field
• Start multiplexing
This adds a new track property in JSON/verbose identification mode
called "multiplexed_tracks". It's an array of track IDs that describe
which of the tracks mkvmerge reports as separate ones were originally
part of the same source track (e.g. TrueHD+AC-3 in a single track in
MPEG transport streams).
Implements #1835.
When the user specifies tracks with "--track-order a,b,c…", she expects
track a to be assigned track number 1, b to be assigned track number 2
and 3 for track c.
The old code did not guarantee this. Instead it might assign track ID 1
to a track not listed in "--track-order".
Fixes the second part of #1832.
The JSON parser will be used for an option file when the file name ends
in ".json". Such an option file must consist of a single JSON array
containing solely JSON strings.
The source will start using the following features from the C++14
standard:
• the "std::make_unique()" Standard Library function
• digit separators
• binary literals
• generic lambdas
gcc's v4.9.x and clang's v3.4 are the oldest releases to support all of
them.
MPLS playlists can contain sub-paths that reference subtitle tracks in
other files than the main audio/video tracks (mostly HDMV TextST
subtitles, it seems). Support for reading the tracks from those files
has been added.
The lock file has proven to be a source of problems time and again on
Windows, see e.g. #1805. In most instances a stale lock file was still
present though the process it referred to wasn't running anymore. Qt is
supposed to clean up such stale lock files automatically, but that
didn't work reliably. The result from the user's POV was that the GUI
simply didn't start as neither the prior instance was still running nor
was the new one showing its UI.
Therefore we just skip trying to lock that file. Instead the new
instance will simply try to connect to the communication socket. If that
connection succeeds, it can be reasonably sure another instance is
running. If it fails, though, the GUI simply removes any lingering
socket file and tries to set it up again. Even if the removal &
subsequent setup fails, the GUI should still come up as a second
instance.
The GUI will now cache file identification results on disc. When the
same file is identified a second time the cached results are used
instead leading to a huge speed gain, especially when scanning Blu-ray
playlists multiple times.
Both positive and negative results are cached.
Cache results are invalidated whenever one of the following conditions
is met:
• if the source file's modification time stamp differs from when the
result was cached
• if the source file's size in bytes differs from when the result was
cached
• if the current version of MKVToolNix GUI differs from the version used
to write the cached result
At the end of 2014 Mike from MakeMKV and me where debating how to store
TextST in Matroska. MakeMKV was already able to do that and used this as
the format for CodecPrivate:
• One byte: character set used according to "Blu-ray Disc Read-Only
Format: table 5-22: Character code"
• n bytes: the "dialog style segment"
• 2 bytes: number of frames in the file
This information partially superfluous, partially harmful. We decided to
only allow UTF-8 in Matroska (we only had Blu-rays that used UTF-8
anyway; this gets rid of the first byte). We also decided that having a
frame counter served no purpose (the format doesn't need it, nor should
players require such information up front), and it made splitting &
joining operations harder than they have to be.
Therefore current versions of MakeMKV only include the "dialog style
segment" in CodecPrivate, and that's what mkvmerge will do, too.
The Matroska reader was already producing the new format.
The bitstream duration will only be updated if it differs at least
1ms. This restriction is in place in order not to modify the bitstream
data just because Matroska's default resolution for timestamps is only
1ms.
This is the second and last part of the fix for #1771.
The bitstream duration will only be updated if it differs at least
1ms. This restriction is in place in order not to modify the bitstream
data just because Matroska's default resolution for timestamps is only
1ms.
Fixes#1771.
In some h.264 bitstreams the SPS and/or PPS settings change, meaning the
bitstream contains SPS/PPS NALUs with an ID that was encountered before,
but with different content. The specs say that the newly encountered
SPS/PPS settings are to be used from that point on.
So far this wasn't properly handled by mkvmerge. It would only include
the changed SPS/PPS NALUs at the point where the change
occurred. However, an application seeking to a point after such a change
would have no knowledge of the change and use the SPS/PPS from the AVCC
stored in CodecPrivate. It would therefore try to decode the pictures
with the wrong settings leading to image corruption and worse.
With this change mkvmerge will include all currently active SPS and PPS
NALUs in front of every key frame (every frame marked as "key" in
Matroska, that is) once it encounters at least one SPS or PPS NALU with
changed content.
Fixes#1711.
On Blu-rays PCM audio with an odd number of channels will still contain
empty bytes for an extra alignment channel (e.g. with 3 channels at 24
bits/sample the source actually contains 3+1channels * 24bits/channel /
8bits/byte = 4 * 3bytes = 12 bytes.
That extra "channel" is located after all the others and only contains 0
bytes.
mkvmerge will now simply remove these extra bytes. Otherwise players see
and use more data than the timestamps and track parameters imply causing
both noise artifacts as well as slowed playback.
The original code tried all four possible combinations of byte swapping
yes/no and 14-in-16 yes/no and aborted as soon as a single DTS header
was found. This can be a false positive, though, and with one test file
provided by a user this has indeed been the case.
The new code does the same detection but requires five consecutive DTS
headers to be found before the detection is deemed to be successful.
