The prior implementation checked each subtitle timestamp against the
last audio or video timestamp seen. If it differed too much, the
subtitle timestamp was set to that last timestamp.
The problem with such an approach is its coarseness. It also disregards
the relative difference between subtitle timestamps.
The new implementation works differently. The first time a big
difference between subtitle and audio/video timestamps is detected, the
difference will be stored. This difference will then be applied to all
subtitle timestamps. This keeps the relative difference between subtitle
timestamps intact.
Addresses #1841.
There are MPEG TS files where subtitle packets are multiplexed with
audio and video packets properly, meaning that packets that are supposed
to be shown/played together are also stored next to each other. However,
the timestamps in the PES streams have huge differences. For example,
the first timestamps for audio and video packets are around 00:11:08.418
whereas the timestamps for corresponding subtitle packets start at
09:19:25.912.
This workaround attempts to detect such situations. In that case
mkvmerge will discard subtitle timestamps and use the most recent audio
or video timestamp instead.
Implements #1841.
Forcing an update check each time the GUI's started was only done for
debugging purposes. The intention was to have it depend on the
environment variable FORCE_UPDATE_CHECK, just like before the change to
"always true".
Before commit e1e14ed Track::setDefaults() was only called for regular
tracks (audio, video and subtitle tracks). After that commit the
function is called for all tracks including chapters, tags and attached
files. Therefore it must be able to handle it, too.
Before the defaults were applied before the result was stored in the
cache. The problem with that is that changing the defaults in the
preferences did not affect cached results. Adding a file the second time
was using cache data which had the old defaults applied.
Now the defaults are applied after the result has been stored in the
cache. Upon retrieval from the cache the current defaults are applied,
too.
In this case the track contains MP3 data. However, the ESDS's object
type ID field is set to 0x6b in the headers indicating MP2. Additionally
the track's fields for channels & sampling frequency are set to 0.
Fixes#1844.
Normally QNetworkAccessManager is supposed to provide an asynchronous
interface to network requests. Unfortunately, the very first call to
QNetworkAccessManager::get() for each URL takes quite a long time,
e.g. more than two seconds on my Windows installation. This is even
before the request is actually started. As this happens on the main
thread it blocks the UI.
In MKVToolNix the update check is started during the GUI's startup
process. Any kind of blockage of the main thread is very noticeable and
annoying.
This seems to be due to the following but in Qt:
https://bugreports.qt.io/browse/QTBUG-10106
