Logic's more straight forward to implement there instead of having to
check in `configure`, adding a variable to `build-local.in` and using
that variable later on. The logic's the same in both places anyway.
mkvmerge tries to find the Blu-ray base directory when handling
certain files that can occur on a Blu-ray such as M2TS or MPLS play
list files. It tries to find additional files with as the streams
referenced in the play lists or clip information files from the CLPI
sub-directory.
That function simply crawls the path upwards to the root of the file
system. This works nicely with Unix paths (`/path/to/file.m2ts`) or
normal Windows paths (`C:\path\to\file.m2ts`). Things go wrong on
Windows with UNC paths, though (`\\servername\sharename\path\to\file.m2ts`).
mkvmerge looks for `\\servername\sharename\path\to\index.bdmv` and
then iterates back towards the server name. As soon as the path to
check removes the share name, the check for the resulting
`\\servername\index.bdmv` will throw a
`boost::filesystem::filesystem_error` with the message that the server
in question doesn't offer a share named `index.bdmv`. That exception
must not bubble; instead the algorithm must simply stop at that point
and return unsuccessfully.
Fixes#2507.
According to issue #2508 a self-compiled version of `mkvextract`
misbehaves if the option `-fvisibility=hidden` is used. As building my
own DMG without the option works just fine, and as the resulting
programs work fine, too, I'll simply drop both flags from the build
process altogether.
Fixes#2508.
The "portable or installed" detection looks for a file called
`portable-app` located in the `data` sub-directory of the directory
the GUI's executable file is located in. For this to work the path to
the executable file must be determined.
Before the fix this was done in the constructor of the `App` class,
which is rather early, but not early enough as the earliest code
trying to access the settings file (and therefore the earliest code
requiring knowledge of the executable's path) is actually run directly
from `main` long before `App` is instantiated.
When that code is run before the executable's path is determined, the
path to the executable is left empty. Therefore the GUI looks in the
current working directory for the `data\portable-app` file. This works
if the current working directory is the same the executable is located
in, e.g. you open Windows Explorer, navigate to the GUI's installation
folder and double-click the executable. In that case determining if
the application is portable or installed works just fine.
However, the working directory might be set to something completely
different. For example, the "open with" functionality sets the working
directory to the directory the file that the user calls "open with" on
is located in. The GUI then looks for `data\portable-app` in the same
directory the clicked-on file resides in and will not find
it. Consequently the GUI thinks it's been installed and looks for the
settings file in the user's `AppData\local\bunkus.org\mkvtoolnix-gui`
directory.
The fix is to initialize the MKVToolNix common library and with it the
current executable's location first thing from `main`, before the
GUI looks for the settings file for the first time.
Fixes#2501.
The pimpl idiom (data members stored in a private class) requires that
the main base class stores a pointer to the private class
instance. This pointer's type must be the private base
class. Obviously the pointer may point to an instance of a derived
private class.
Deletion happens via the private base class. If the destructor of that
class hierarchy isn't virtual, only the private base class's
destructor is called, even if the pointer points to a derived private
class. Consequently the destructors of data member in derived classes
aren't called either.
This is a problem for data members that need to clean up after
themselves, such as temporary files that should be deleted whenever
the
Fixes#2499.
avilib doesn't support DV type 1 AVIs at all. It used to print an
error message to standard error; additionally it didn't propagate the
error back to the caller resulting in invalid memory accesses and
subsequent crashes.
Fixes#2491.
Qt's drag & drop handling was refactored for 5.12.0. One effect is
that somewhat sloppy programming that worked before fails now. In this
particular case the multiplexer's `Tab` widget (which is the top-most
widget for each multiplexer tab) hat its `acceptDrops` property set to
`true` but didn't implement the corresponding functions.
The desired behavior was that the `Tool` class, which implements the
container for all the `Tab` instances, receives the D&D events. So the
solution is simple: if you don't reimplement the D&D functions, don't
have your `acceptDrops` property set.
Additional fixes were required for the two `BasicTreeView` elements:
those handle D&D already, but the `Tab` class didn't connect to their
"files were dropped" signal correctly.
Fixes#2472.
Various places needed to differentiate better between "no duration is
known or set for this packet" and "this packet has a duration of
0ms". The former means that no duration element should be written to
the file, and the use of `SimpleBlock` instead of `BlockGroup` is
OK. The latter on the other hand means that a `BlockGroup` must be
used and a duration element must be added.
This core change uncovered a couple of subtle bugs in other places
where subtitles were handled:
• The Matroska reader passed 0 as the duration even if no duration
element was present making it impossible for other code to
differentiate between "no duration present" and "duration present
but set to 0".
• The DVB subtitle packetizer always enforced writing the duration
even if the duration wasn't known.
• The Kate packetizer used a wrong dummy value of 1us for the duration
for the "end of stream" packet as the core would not write a
duration of 0.
• The text subtitle packetizer was using the difference between the
current packet and the following one for packets were the duration
was 0 or unknown. The correct behavior is to do this only if the
duration is unknown, not if it is 0.
Fixes#2490.
