Specially crafted files can lead the parsing code to take too long.
We fix a lot of these problems by not allowing local tags to extend past the
end of the set and not allowing other KLVs to be read past the end of
themselves.
Only the OPAtom demuxing logic is guaranteed to have index tables, meaning OP1a
files that lack an index would cause SIGSEGV.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The last entry is the total size of the essence container.
Previously a TemporalOffset error would be logged, even though segments like
these are expected.
This uses the old demuxing code for OP1a and separate demuxing code for OPAtom.
Timestamp output is added to the old demuxing code.
The seeking code is made to seek to the start of the desired EditUnit only,
from which the normal demuxing code takes over (if OP1a). This means we don't
use delta entries or slices, only StreamOffsets.
OPAtom seeking basically works like before.
This also makes D-10 seeking behave the same way as OP1a and OPAtom. In other
words, we allow seeking before the start or past the end for D-10 too.
This fixes ticket #746.
This changes mxf_compute_ptses() to be used for MXFIndexTable, and also adds
code for computing the fake index to it.
This also temporarily disables PTS computation. A future patch will restore it.
These indexes duplicate every entry and have the total size of the essence
container as the last entry.
This patch also computes the size of the packets when unknown.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
I thought it had to do with file offsets, but's actually the offset inside
the essence container.
In other words, unbreak multiple EditUnitByteCounts.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
These values include KAGSize, HeaderByteCount and IndexByteCount.
The length of the pack itself is also stored, and KAGSize is sanity checked.
The FATE sample has KAGSize == 0, which is adjusted to 512.
Other bad KAGSizes are set to 1.
Specifically, this means parsing as before until we run into essence.
At that point we seek to the footer and parse until EOF. After that we start
seeking backward to the previous partition and parse that until we run into
essence or the next partition. This procedure is repeated until we encounter
the last partition we parsed in the forward direction.
The end result of all this is that large essence containers aren't needlessly
parsed. This speeds up parsing large files a lot.
Tomas Härdin
Reimar Döffinger
Daniel Huang
Jean First
Carl Eugen Hoyos
Anton Khirnov