Casting directly from certain values of
`boost::multiprecision::mpq_rational` via `static_cast<int64_t>()`
fails on certain platforms (32-bit ones, mingw both 32 & 64-bit). A
workaround seems to be to convert to `boost::multiprecision::int128_t`
first.
See https://github.com/boostorg/multiprecision/issues/342
The older versions have incomplete constructors for
`boost::multiprecision::number` when used with the `gmp_rational`
backend. When trying to specify both a numerator and a denominator,
the numerator argument is supposed to be a `gmp_rational` while the
denominator can only be an (unsigned) int. This means that trying to
pass a 64-bit integer as the denominator will not work as no matching
constructor is found.
The workaround is to convert both the numerator and the denominator to
instances of `…number<gmp_rational>` and passing those to the
constructor of `…number<gmp_rational>`.
This reverts commit b46089387c.
With the patch applied the default copy constructor only copies the
shared pointers to the other files & tracks & attachments — but we
need a deep copy here. Otherwise invalid memory access will happen (or
rather, the GUI's `MuxConfig::verifyStructure()` recognizes the
problem and aborts with the message "track->m_file == nullptr in level
0 file").
Fixes#3157.
Two advantages:
1. This way invalid UTF-8 characters will be replaced by the Unicode
Replacement Character U+FFFD instead of keeping invalid UTF-8
encodings in text.
2. Preparation for the conversion from (J)PCRE2 to QRegularExpression
which requires converting between UTF-8-encoded `std::string` and
QString.
A sequence is detected as follows:
1. The current file name is split into three parts if possible: a
prefix, a running number and a digit-less suffix.
2. If successful, the result is compared with the result of the same
split for the previous file name. They're considered to be in
sequence if the previous file name's prefix & suffix match the
current file name's prefix & suffix and if the current running
number is higher than the previous one by 1.
In such a case only the first file is added. The other files in the
same sequence will be appended to the first one.
Implements #2866.
The order is: video first followed by audio, subtitles and other
types.
For files this means that a file without video tracks will be inserted
after one with one or more video tracks.
In general the files & tracks are inserted before the first
entry (file respectively track) that has a lower priority than the
entry to insert. For example, let's assume that the user has already
added one video, three audio and three subtitle tracks and they're
currently ordered as follows:
* existing video
* existing audio 1
* existing audio 2
* existing subtitles 1
* existing subtitles 2
* existing subtitles 3
* existing audio 3
When adding audio track number 4 the GUI will start comparing the
track priorities starting at the top. The first existing entry with a
priority lower than the new entry to add (a new audio track) is the
first subtitles track, "existing subtitles 1". The new order will
therefore look as follows:
* existing video
* existing audio 1
* existing audio 2
* newly added audio 4
* existing subtitles 1
* existing subtitles 2
* existing subtitles 3
* existing audio 3
This option only determines the initial order. The user can still
change the order manually as they see fit afterwards.
The option is enabled by default.
Implements #2366.
