Associated clip information (CLPI) files contain an index that map
timestamps to file positions (roughly one index entry per
second). When reading an MPLS playlist mkvmerge will now look up each
play item's start timestamp in said index and seek to the nearest file
position and start processing from there — instead of always reading
an M2TS file from the start.
Additionally mkvmerge will now simply stop reading from an M2TS file
once the first packet is encountered whose timestamp is equal to or
larger than the play item's end timestamp. Before the change mkvmerge
would continue reading the rest of the file, potentially accepting
packets whose timestamps are again smaller than the play item's end
timestamp. Not only was that behavior wrong (processing of a play item
must stop once the first timestamp higher than the play item's end
timestamp is encountered), it was also wasting a lot of time.
For file reported in #2824 this reduced overall remuxing time from
more than one hour down to five minutes.
Part of the fix of #2824.
An MPLS playlist consists of one or more play items. Each play item
has a start and end timestamp. The intended use of the start
timestamp: locate the first packet whose timestamp is equal to or
larger than the play item's start timestamp. Demux that and all
following packets.
Unfortunately mkvmerge interpreted the timestamp differently. It would
compare the timestamps of all packets to the play item's start
timestamp. This is problematic when the timestamps aren't strictly
monotonic, which they often aren't.
For example, on a certain Blu-ray the timestamps for a PGS subtitle
track would look like this:
1. PTS 00:02:46.054911111 PGS type 22 (Presentation Composition)
2. PTS 00:02:46.050422222 PGS type 23 (Window Definition)
3. PTS 00:02:46.041455555 PGS type 20 (Palette Definition)
4. PTS 00:02:46.050422222 PGS type 21 (Object Definition)
5. PTS 00:02:46.050422222 PGS type 128 (End Of Display)
With the play item's start timestamp at 00:02:46.054911111 mkvmerge
would drop packets 2–5 and only keep 1 — destroying the PGS entry in
the process.
Additionally this resulted in the timestamps of the following PGS
subtitle being wrong: it would use the timestamp of the garbled first
entry instead.
Part of the fix of #2824.
Said heuristic is supposed to recognize faulty files where the
timestamps of teletext subtitles suddenly differ hugely from the
timestamps of surrounding audio/video packets. They often jump back
just as quickly.
Unfortunately regular PGS subtitles as found on regular Blu-rays show
similar behavior. For example:
audio @ 00:00:56.170
subtitles @ 00:00:56.181 (contains content to display)
audio @ 00:00:56.202
audio @ 00:00:56.234
subtitles @ 00:01:05.649 (this is the "stop displaying" packet)
audio @ 00:00:56.266
Here the subtitle packets aren't interleaved by their timestamps with
audio/video properly, triggering the heuristic, which in turn will
reset the timestamp of the second subtitle packet (stop displaying),
often to be smaller than the timestamp of the first subtitle
packet (display something). In such a case the player sees the "stop
displaying" packet before the "display something" packet, and the
result is that something is displayed indefinitely (or until the next
"display something" subtitle comes along).
As such interleaving seems to be normal on Blu-rays, turning off the
heuristic for PGS subtitle tracks is the way to go — especially since
I've never seen huge jumps in PGS subtitle timestamps such as the ones
the heuristic was initially meant for.
Fixes#2736 and partially fixes#2824.
In dark mode this icon doesn't contrast well with the dark background. I've added a tint of white shadow, so now it looks kind of okay on dark background.
That information contains an index mapping timestamps to file
positions. It'll be used by the MPEG transport stream reader to
quickly seek to the start position when handling MPLS playlists.
PES packets with an unbounded size only end at the start of the
following PES packet for the same track (a TS packet with the "payload
unit start" flag set for the same PID). For tracks that consist only
of a single PES packet there is no "following PES packet for the same
track", obviously. Therefore the end of the file counts as its end,
too.
Part 2/2 of the fix for #2849.
Otherwise tracks consisting of a single key frame won't be detected as
those key frames are buffered by the parsers in order to determine
frame order.
Part 1/2 of the fix for #2849.
The previous default list was derived from the list of spoken
languages sorted by native speakers. This list was so long that in
addition the option "only show often used languages" was enabled so as
not to confuse users with very long drop-down boxes where the top list
was very long.
Unfortunately this resulted in users being confused because their
particular language wasn't present in the drop-down boxes, and they
didn't know that this is a feature that can be customized.
The default settings matter a lot for user experience; most users
rather assume the program's buggy than they can configure a specific
feature to work as they expect.
The new default is to only include the following entries at the
top and all the other available languages below (meaning "only show
often used languages" is off by default again):
- mul: multiple languages
- zxx: no linguistic content
- qaa: reserved for local use
- mis: uncoded languages
- eng: English
Additionally the system's default user interface language will be
included, too.
Implements #2716.
The previous default list was derived from the list of spoken
languages sorted by native speakers.
Unfortunately this resulted in users being confused because their
particular language wasn't recognized in file names, and they didn't
know that this is a feature that can be customized.
The default settings matter a lot for user experience; most users
rather assume the program's buggy than they can configure a specific
feature to work as they expect.
The new default is to include all languages by default. Advanced users
can still remove languages if they encounter too many false positives.
