[FFmpeg-devel] [PATCH] lavf/mxfdec.c: fix MXF essence body offsets when only 1 body partition

[Jason Livingston]

On Friday, March 08, 2013 4:17 AM, ffmpeg-devel-bounces at ffmpeg.org [ffmpeg-devel-bounces at ffmpeg.org] on behalf of Matthieu Bouron [matthieu.bouron at gmail.com] wrote:
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] lavf/mxfdec.c: fix MXF essence body offsets when only 1 body partition
> 
> On Wed, Mar 06, 2013 at 04:37:57PM +0000, Jason Livingston wrote:
>> I was having trouble with some Avid OP-Atom MXF files that contain only 1 essence track and only 1 body partition with all the frames.  After the first call to av_read_frame(), it would return AVERROR_INVALIDDATA from mxf_absolute_bodysid_offset():
>> [mxf @ xxx] failed to find absolute offset of 100 in BodySID 1 - partial file?
>>
>> The attached patch fixes this case which is probably pretty rare, but it shouldn't negatively affect anything else.
>>
>> Unfortunately I can't distribute my sample file but I could probably construct one if necessary.
>>
> 
> Hello,
> 
> Can you provide a sample ?
> 
> Thanks in advance,
> Matthieu

Hi Matthieu,
My case is a bit weird as I am reading frames of metadata using lavf and av_read_frame() from a file that contains no video or audio tracks, but here is a sample file: https://dl.dropbox.com/u/7730988/aviddata.mxf

You can run ffmpeg like this although the result isn't terribly useful unless you are interested in this metadata. :)
ffmpeg -i aviddata.mxf -map 0 -codec copy -f rawvideo out.raw

Before the patch, the 2nd call to av_read_frame() returns AVERROR_INVALIDDATA and prints this message:
[mxf @ 0x10180f200] failed to find absolute offset of 100 in BodySID 1 - partial file?
aviddata.mxf: Invalid data found when processing input

After this patch, there is still a read error but it happens after the last data frame, so the output file successfully contains all the raw data from the input file. 

I noticed that getting a read error after reaching the last frame is fairly common when reading MXF files in ffmpeg and so I can take a look at that as a separate issue if you'd like, but it should not detract from the validity of this patch.

Thanks,
Jason