The old code was pretty convoluted and hard to reason about. On top of
that it didn't buffer PES packets properly before trying to parse the
PES headers. This lead to accesses beyond the end of the buffer.
Updated the list of valid top level domain country codes. Deprecated
codes such as "gb" are mapped to their current representation ("uk")
during merging, extraction, in the GUI's chapter editor and in its
preferences.
Fixes#1731.
This re-writes the "parse_number_with_unit" not to use the "double" data
type internally but int64_t-based fractions. This fixes issues with
"double" precision on certain 32bit platforms and test cases failing.
This is a fix for #1705.
Due to this change the handling of the syntax "1234/56i" with "i" as the
unit was fixed as well. Before the value was wrongfully multiplied
instead of divided by 2 leading to quadruple the expected value being
returned. This was mentioned in and fixes part of #1673.
The overwrite function already takes care of updating the element's size
properly. Therefore it doesn't have to be done by mkvmerge before
calling the function, especially if it's called wrong:
- our manual call doesn't include elements with default value in the
calculation
- the replacement request does
This led to the situation where mkvmerge thought that the new chapters
would fit into the void while the replacement function disagreed causing
the chapters not the be written at all.
Fixes#1693.
This reverts commit d5b87747b5.
The reason is that this seems to be the wrong thing to do; not all such
frame types are actually independently decodable. See the discussion in
issue #1671.
In MP4 such samples aren't marked as sync points but they are marked as
random access points by way of the "rap " atom. In Matroska both kinds
of samples have to be marked as key frames.
Fixes#1671 where only open GOP key frame sequences occur and no regular
key frame sequences (IDR NALUs with I or SI slices) causing mkvmerge not
to find any key frames and to buffer the whole file before writing it out.
Due to the addition on new mandatory elements the calculation of default
sizes for void elements is different. Therefore most test cases have had
their checksums updated.
Some of the sub-tests in 449 have to work with uninitialized data due to
the file structure errors in the source files. Therefore the data's
content may actually change from run to run. Such a change was triggered
with change f82360d. Therefore only test whether or not muxing succeeds
for those sub-tests, not what the actual content looks like.
kax_file_c has built-in error resilience and will re-sync to the next
level 1 element in case of a structural error. This way a structural
error before the first cluster won't cause mkvmerge to abort the reading
process.
Fixes#1654.
Frontends like gMKVExtractGUI currently use mkvinfo for determining the
offset between tracks. This is an attempt to provide that information
with mkvmerge.
The currently queued frames must be flushed before either a progressive
key frame or before the first field of an interlaced key frame. The
first field may also be the bottom field even though that is rare.
The sample file in question contains many teletext packets that show the
same content. The old code would convert those to separate Matroska
frames.
Additionally each frame's duration was calculated from the wrong
timestamp. A teletext page can be drawn over the space of several
packets with different timestamps. Therefore the timestamp of the first
packet rendering a line of a teletext page must be used as the start
timestamp, and the timestamp of the first packet rendering a line of the
following teletext page as its end.
The old code was using a wrong packet for the end, though: the timestamp
of packet containing the end-of-page block.
Fixes#1623.
This reverts commit 8a1e641762.
The aforementioned commit 8a1e641 changed mkvmerge's behavior regarding
SEI NALUs. Before 8a1e641 mkvmerge would include all SEI NALUs it
encountered together with the following slice NALUs in a Matroska block.
Commit 8a1e641 changed this to drop those SEI NALUs instead. The reason
for dropping it was that mkvextract re-creates certain types of SEI
NALUs from information stored in the HEVCC (codec private
data). Therefore this information was actually duplicated in the
extracted bitstream. With 8a1e641 the duplication did not happen
anymore.
Unfortunately only certain types of SEI NALUs are actually stored in the
HEVCC (user data information SEIs), others are not stored there. The
result of 8a1e641 was that those other SEI NALUs were irrevocably lost
during muxing. Therefore this fix is now reverted which fixes#1621.
The duplication in mkvextract will be tackled with a separate commit.
