[FFmpeg-devel] [PATCH] Clip-Wrapped MXF support (attempt #4)

[Tomas Härdin]

Maksym Veremeyenko skrev 2011-02-14 14:17:
> Tomas H?rdin ???????(??):
> [...]
>>>> I'd need a place to upload them to. There's four of them, ranging from
>>>> 100 megs to 400 megs each. Since they have the index in the footer I
>>>> can't cut them down to size for upload to the MPlayer ftp.
>>> could you upload this file to my ftp if i provide you with
>>> login/password?
>>
>> Yes, of course.
>
> First, thanks for files.
>
> The files you provided has AVID (i think) essence identifier:

Not surprising, since they were created by Media Composer as I said.

> that actually not listed in *RP 224.10* (http://www.smpte-ra.org/mdd/),
> so they (files) are not good for testing new feature in ffmpeg...

Well, lavf supports lots of broken/non-standard formats. But this is a 
discussion for another thread.

> anyway we can try to do some assumption about uls and apply attached patch.
>
> as result:
>
> [root at story-parts ffmpeg]# ./ffmpeg_g -debug 5 -i
> /mnt/spool/tmp/devels/mxf/tidkod-svep-avcintra50-960x720-25.mxf -an
> -vcodec copy -f rawvideo -y
> /mnt/spool/tmp/devels/mxf/tidkod-svep-avcintra50-960x720-25.h264
>
> /.../
> [mxf @ 0x9a507a0] only frame wrapped mappings are correctly supported
> [mxf @ 0x9a507a0] read packet 06.0E.2B.34.01.02.01.01
> 0D.01.03.01.15.01.06.01
> [mxf @ 0x9a507a0] size 105250816 offset 0x5ffe7
> [mxf @ 0x9a507a0] Clip-wrapped reading. mxf->current_klv_bsize=65536,
> klv.length=105250816
> [mxf @ 0x9a507a0] read packet data 06.0E.2B.34.01.02.01.01
> 0D.01.03.01.15.01.06.01
> [mxf @ 0x9a507a0] data size 65536 offset 0x5ffe7
> /.../
>
> [root at story-parts ffmpeg]# ls -als
> /mnt/spool/tmp/devels/mxf/tidkod-svep-avcintra50-960x720-25.h264
> 102784 -rw-r--r-- 1 root root 105250816 ??? 14 15:12
> /mnt/spool/tmp/devels/mxf/tidkod-svep-avcintra50-960x720-25.h264
>
> as seen resulted file is 105250816 bytes exactly the same as logged
> above: /size 105250816 offset 0x5ffe7/
>
> so... no garbage found...

I'm not sure if you see my point. EditUnitByteCount does not divide 
105250816. Hence the code, if given the correct EditUnitByteCount 
(140288), outputs 751 packets instead of 750.

To be more specific, it outputs that many packets if you turn off full 
parsing, or use a codec for which there is no parser (like rawvideo) AND 
use the correct EditUnitByteCount. The H.264 parser might fix the output 
a bit though. Try running ffprobe -show_packet 2>&1 | grep type=video | 
wc and verify that it outputs 750 packets in the end.

Finally, the real EditUnitByteCount can only be guaranteed to be in the 
footer (see S390m). The original code stops parsing metadata once it 
comes across the first essence container, since it seems to be designed 
to parsing only Op1a. Hence it doesn't parse the index at all.

/Tomas