[FFmpeg-devel] [PATCH 04/11] libavformat/mxfdec.c: Try to increment current edit before rejecting a klv that spans onto next edit unit.

[Alexis Ballier]

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