The reason for this is that such files have IndexTableSegments which when parsed
cover EditUnit ranges like this:
[0,1)
[249,250)
[249,377)
[0,249)
where each interval is [IndexStartPosition,IndexStartPosition+IndexDuration).
This would be reduced to a sparse index like:
[0,1), [249,250)
instead of the full range:
[0,249), [249,377)
See TimeCode_HD.mxf, UMID =
060a2b340101010101010410130000000004001aa0e59175025b2a5600da4101.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
We can't do this in general since we could be reading a file with B-frames while
lacking an index.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The "ECs != 1 -> OP1a" assumption was wrong. Luckily, the file that triggered
that behavior had two ECs, not zero. Hence distinguishing between them is
simple in this case.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes rare cases where OPAtom may be treated as OP1a, causing all essence
to be read into RAM.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The properties of the CDCI Descriptor are insufficient to specify
the pixel format for uncompressed picture data. SMPTE 377-1 and
RP224v10 have defined a set of picture coding labels to indicate what
formatting was used.
This patch uses 2 labels to detect UYVY422 or YUYV422 pixel formats.
It defaults to UYVY422 for 8-bit 4:2:2 pictures to support files
that were created before the coding labels were introduced ~2008
The codec pix_fmt default was changed from 0 (PIX_FMT_YUV420P) to
-1 (PIX_FMT_NONE)
Reviewed-by: Baptiste Coudurier <baptiste.coudurier@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This supports detection of uncompressed picture in files that
didn't include a Picture Coding Label. The lables weren't
available until SMPTE 377-1 and RP224v10
Reviewed-by: Baptiste Coudurier <baptiste.coudurier@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This matches the order used for the index table edit rate.
Reviewed-by: Baptiste Coudurier <baptiste.coudurier@gmail.com>
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.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
These are common with audio atoms. Without this the demuxer would read two
bytes at a time for a mono 16-bit file.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
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.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
This can happen if an index table segment has a very large IndexStartPosition.
zzuf3.mxf is an example of such a file.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Only the OPAtom demuxing logic is guaranteed to have index tables,
meaning OP1a files that lack an index would cause SIGSEGV.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
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
do not 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.
Based on several patches by Tomas Härdin <tomas.hardin@codemill.se> and
Reimar Döffinger <Reimar.Doeffinger@gmx.de>.
Changed av_calloc to av_mallocz, added overflow checks.
It is a really bad idea to assign a video codec id
when we have set codec_type to audio and vice versa.
Prevents detection of mp2 in mxf as mpeg2video.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
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 are not needlessly
parsed. This speeds up parsing large files a lot.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
This fixes 0001GL.MXF.V1.mxf_opatom.mxf and 0001GL00.MXF.A1.mxf_opatom.mxf
getting two streams each due to both using the same SourcePackageID.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
Michael Niedermayer
Matthieu Bouron
Reimar Döffinger
Tomas Härdin
Joseph Artsimovich
Philip de Nier
Anton Khirnov
Jean First
Janne Grunau
Carl Eugen Hoyos