With just a single page the `m_previous_page_end_timestamp` variable
is still an invalid timestamp. However, in such a case the page's
granulepos cannot can only indicate an end trimming but not a starting
timestamp != 0. So assume timestamps start at 0 in such cases.
Fixes#2722.
This was already done when SPS or PPS NALUs were found with the same
ID as active SPS or PPS but with different content. The missing case
were SPS or PPS NALUs whose IDs hadn't been seen before.
After such an encounter all following key frames must be prepended
with the active SPS & PPS, too. Otherwise seeking would not work as
the player only used the SPS & PPS from CodecPrivate but didn't know
about the new ones from mid-stream.
Part of the fix of #2250.
The standard clearly states the order in which NALUs must be written
in ITU-T "h.264 (10/2016)" section 7.4.1.2.3 "Order of NAL units and
coded pictures and association to access units".
Fix by Torsten Hauska. Part of the implementation of #2709.
There are eight bytes (type & unknown fields) before the attachment's
data. Those eight bytes must be subtracted from the atom's data size;
otherwise too much data would be read for the image. When the image
was located at the end of the file, mkvmerge would throw an exception
due to running into the end of the file, causing file identification
to fail.
Even if identification succeeded, the resulting attachment would
contain eight bytes too many at the end.
Fixes#2650.
Problematic were files for which DOS-style EOLs were
detected (carriage return followed by newline, \r\n) but which had
some lines terminated solely by a newline (\n). In such a case the
EOL was only detected upon seeing the next \r\n, and the value
returned from the `getline()` function would return something that
everyone would judge to be multiple lines of text.
Fixes#2594.
This pulls the fixes for handling Unicode code points >
U+FFFF. Also update the one test case with invalid data which is now
handled slightly differently than before.
Part of the fix of #2516.
Various places needed to differentiate better between "no duration is
known or set for this packet" and "this packet has a duration of
0ms". The former means that no duration element should be written to
the file, and the use of `SimpleBlock` instead of `BlockGroup` is
OK. The latter on the other hand means that a `BlockGroup` must be
used and a duration element must be added.
This core change uncovered a couple of subtle bugs in other places
where subtitles were handled:
• The Matroska reader passed 0 as the duration even if no duration
element was present making it impossible for other code to
differentiate between "no duration present" and "duration present
but set to 0".
• The DVB subtitle packetizer always enforced writing the duration
even if the duration wasn't known.
• The Kate packetizer used a wrong dummy value of 1us for the duration
for the "end of stream" packet as the core would not write a
duration of 0.
• The text subtitle packetizer was using the difference between the
current packet and the following one for packets were the duration
was 0 or unknown. The correct behavior is to do this only if the
duration is unknown, not if it is 0.
Fixes#2490.
Unsupported edits such as dwells were simply ignored. If all of them
were ignored, then the new timeline was empty resulting in no data
being copied for that track. Instead simply ignore edit lists whose
new timeline ends up empty after the entries have been processed.
Fixes#2487.