MP4 DASH files can contain more than one copy of the "moov"
atom. Parsing it multiple times would mean that tracks, chunk offset
tables, sample to chunk tables etc. would be filled multiple times as
well.
Commit 2b5e8c86a6 made this easier to
trigger, though the problem could have been hit with earlier code,
too. Before that commit header parsing stopped as soon as the first
"moov" and "mdat" atoms were found. Multiple "moov" atoms before the
first "mdat" atom would therefore have triggered the bug, but I'm not
aware of that having ever happened.
Fixes#1877.
The old code used a way of iterating over the table that would get hung
up on duplicate entries. Additionally it relied on the table being
sorted in ascending order in the source file.
The result in such a case was that only key frames up to and including
the first duplicate frame index in the key frame index table were marked
as key frames in the output file, even though more key frames index
entries might exist.
The new method simply iterates over the whole table once, from start to
finish, and looks the referenced frames up properly.
This is the last part of the fix for #1867.
The chunk table can be filled via two different kinds of atoms:
• The "stco"/"co64" atoms in the normal "moov" atoms and
• the "trun" atoms in the "moof" atoms used for DASH.
The latter already know often each chunk applies: exactly
once. Therefore their "size" member is already set.
It's different for the chunks read from "stco"/"co64", though. For them
the times they apply (their "size" member) is derived from the chunk map
table. However, the chunk map table only knows a start index into the
chunk table but not an end index. Therefore the last chunk map entry is
applied from its start index until the end of the chunk table.
This overwrites the "size" member that's already set for chunks read
from "trun" atoms, though. The result is that data is read from the
wrong portion of the file.
Part of the fix for #1867.
Edit lists don't have to be different, bu they can be. Therefore do what
ffmpeg does: parse all of them and only use the last one parsed.
Part of the fix for #1867.
The old code was trying to save time by only scanning until the first
"mdat" (the encoded data for all the frames) and first "moov" (track
headers etc.) atoms were found.
If a "moof" (for segmented headers in MP4 DASH) atom was found during
that scan, it switched to scanning all top level atoms in order to find
all other "moof" atoms.
However, there are DASH files where the first "moof" atom is located
behind the first "mdat" and "moov" atoms. Reading such a file mkvmerge
aborted its top-level atom scan before encountering the "moof" atom and
therefore never switched to DASH mode. The result was that only a small
portion of the file was read: as much as was given via the tables in the
"moov" atom.
The new code does away with that shortcut and always scans all top level
atoms. It will therefore switch to DASH mode even if the first "moof"
atom is located behind the first "mdat" and "moov" atoms.
Part of the fix for #1867.
Some source files only provide one timestamp every n AC-3 frames. In
such situations the next provided timestamp might arrive before all of
the data for the previous AC-3 frame has been flushed (due to the AC-3
parser buffering data in order to determine whether or not a dependent
frame is following). The result is a single gap of one frame after frame
number n - 1.
Fixes#1864.
The intention behind keeping the generated man pages is to avoid
requiring downstreams to have xsltproc and the DocBook stylesheets
installed. However, for that they don't have to be stored in the
repository. Generating them upon release and including them in the
source tarball is enough.
The default palette used will not look good in most of the cases, but
it's hard to guess a palette and pretty much impossible without actually
decoding a lot of the packets.
Implements #1854.
