Some files such as those from tickets #2817 & #2776 claim to have constant edit
unit size but,
in fact, have some of them that are smaller. This confuses the demuxer that
tries to infer the
current edit unit from the position in the file. By trying to increment the
current edit unit
before rejecting the packet for this reason, we try to make it fit into its
proper edit unit,
which fixes demuxing of those files while preserving the check for misprobed
OpAtom files.
Seeking is not accurate but the files provide no way to properly find the
relevant edit unit.
Fixes tickets #2817 & #2776.
---
libavformat/mxfdec.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 593604e..526eca6 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2956,6 +2956,18 @@ static int mxf_read_packet_old(AVFormatContext *s,
AVPacket *pkt)
next_ofs = mxf_set_current_edit_unit(mxf, klv.offset);
if (next_ofs >= 0 && next_klv > next_ofs) {
+ /* Samples from tickets #2817 and #2776 claim to have
+ * constant edit unit size. However, some of them are smaller.
+ * Just after those smaller edit units, klv.offset is still in
+ * the same edit unit according to the computations from the
+ * constant edit unit size. If the klv finishes after, the next
+ * check would truncate the packet and prevent proper demuxing.
+ * Try to increment the current edit unit before doing that. */
+ mxf->current_edit_unit++;
+ next_ofs = mxf_set_current_edit_unit(mxf, klv.offset);
+ }
+
+ if (next_ofs >= 0 && next_klv > next_ofs) {
/* if this check is hit then it's possible OPAtom was treated
as OP1a
* truncate the packet since it's probably very large (>2 GiB
is common) */
avpriv_request_sample(s,
--
2.6.2
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
