Example:
The `ekavsk` variant has three prefixes: `sr`, `sr-Latn` and
`sr-Cyrl`. This must be interpreted as "if the language tag contains a
script, it must be either `Latn` or `Cyrl`; no other script subtag is
allowed". Not having a script subtag is allowed as well.
In effect this means that the following three language tags are all
supposed to be valid: `sr-ekavsk`, `sr-Cyrl-ekavsk` and
`sr-Latn-ekavsk`. This part of the validation worked correctly.
However, any other script was considered to be valid as well,
e.g. `sr-Bali-ekavsk`. This was due to the first prefix `sr`, which,
on its own, is a prefix match of `sr-Bali-ekavsk`. This did not take
into account that there are other prefixes that do restrict the script
subtag.
This was fixed. Now only either no script subtag or a script subtag of
`Cyrl` or `Latn` is considered valid.
This patch changed two things. The first is that for all IETF chapter
language elements that don't contain a valid ISO 639-2
code (e.g. because they contain a 639-5 code instead) a legacy chapter
language element set to `und` ("undetermined") is written. Not writing
a legacy element would mean that legacy parsers that don't support
IETF language elements have to use the legacy element's default value
`eng` ("English") in its absence, which is clearly not the language
the author intended.
The second change simply ensures that when multiple legacy or IETF
languages are present, each value will only be written once. This also
effects the situation above: when e.g. two IETF language elements
without 639-2 codes exist in the same chapter display element, only
one legacy element will be written, set to `und`.
Fixes#3174.
When appending tracks, there's one packetizer instance for each source
file, in case of the HEVC packetizer each with its own HEVC ES parser
instance. In order to properly process all parameter sets all
packetizer instances must use the same ES parser instance, though.
So far the appended packetizers only copied the reference to the
preceding packetizer's ES parser instance the moment the connection
was made by mkvmerge's muxing core. This turns out to be too late:
there are situations in which data is passed to the appended
packetizer before that second "connect now" call has been made for
some reason. In that case that data was passed to the appended
packetizer's ES parser instance which is then thrown away in favor of
the preceding packetizer's ES parser instance, losing the frames in
the process.
The fix is rather obvious: copy the reference to the ES parser right
at the start of muxing when the first connection phase is run, before
any data is actually processed by them.
Fixes#3170.
