The old code assumed that there's at most one IETF & one legacy
language element within the same "chapter display" element. This
doesn't have to be the case as the specs lists both language elements
as multiple.
Part of the fix of #3120.
There are elements in Matroska that are mandatory, have a default
value and may occur multiple times within the same master, mainly the
"chapter language" element. The semantics in such a case are that the
default value must only be used if NO OTHER element of the same type
is present within the same master element.
If a "chapter display" contains, let's say, a string for the languages
German & English, two "chapter language" elements must be
used. Checking with the specs reveals that English is the default
value for "chapter languages". Therefore one might think we can omit
writing the instance for "chapter language" with value "English". But
that would leave one "chapter language" element present with "German"
as the value, and semantically that would be the value a reader must
use.
This patch changes how default elements are removed before writing a
master element. It now iterates over all elements keeping track of how
many elements of each type there are within the same master. Mandatory
elements set to their default value will now only then be removed if
there is only that one instance of the mandatory element.
Part of the fix of #3120.
The Matroska specs have recently clarified regarding the intended
interpretation of the "default track" flag. If it is set, it is
supposed to signal to the player that this track is eligible for being
played by default, potentially taking other factors such as user
preferences regarding languages into account.
This implies that more than one track of each type can have this flag
set. For example, a Blu-ray disc with three audio tracks might have
the main audio in both English and Japanese, whereas the third audio
track contains the director's comments. In such a case the first two
tracks should have the "default track" flag set, the third one
shouldn't.
Earlier mkvmerge was enforcing that only one track of each type could
have the flag set. This restriction has been removed.
Part of the implementation of #3092.
When the timestamps & the default duration comes from a container with
low timestamp resolution (= from Matroska), calculating the actual
default duration and frame duration to use requires using the HEVC
stream's frame duration if the delta between it and the source's
imprecise duration is less than the source's timestamp resolution.
Otherwise the cluster helper will often come to the conclusion that a
frame's duration doesn't match the track's default duration. The
result in such cases is that `BlockGroup` elements with
`BlockDuration` elements have to be used to signal the frame's (wrong
because imprecise) duration.
With precisely calculated frame duration the cluster helper will
always see that the frame's duration matches the track's default
duration. It can therefore always use `SimpleBlock` elements and save
on space that way.
Fixes#3114.
1. Parameter set & prefix SEI NALUs are no longer duplicated in front
of key frames.
2. Parameter set & prefix SEI NALUs will now be output in the same
order they're found if they already exist in the bitstream in front
of key frames.
3. Several NALU types, notably Dolby Vision-specific NALUs ("unspecified
62" and "unspecified 63") and suffix SEI NALUs, must be placed in
the same Matroska block but behind the slice NALUs they belong
to. They are now. Earlier they were stored in the following
Matroska block, before the slice NALUs.
Part of fixing & implementing #2784, #2818, #3093 and #3113.
The end position used for subtracting the frame sizes must be the end
position of the `Block` element, not of the containing `BlockGroup`
element as that can contain other elements such as the `BlockDuration`
element.
Normalization means that each key frame is prefixed with exactly one
set of the currently active picture, sequence & video parameter sets.
Fixes#3034 and prevents the same class of issues where the parameter
sets required to decode do not match the ones in CodecPrivate but
aren't present in front of the key frames. This often happens when
appending files.
The effect is that track statistics tags will no longer have a
language set. This turns the effective language of track statistics
tags into "undetermiend" due to the default value of the legacy tag
language element.
Fixes#3073.
