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

[Tomas Härdin]

On Tue, 2013-03-19 at 17:49 +0000, Jason Livingston wrote:
> On Monday, March 18, 2013 4:55 AM, ffmpeg-devel-bounces at ffmpeg.org [ffmpeg-devel-bounces at ffmpeg.org] on behalf of Tomas H?rdin [tomas.hardin at codemill.se] 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, 2013-03-06 at 16:37 +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.
> > 
> > I dunno, the patch looks a little suspicious. Most files I work with do
> > indeed only have one body partition, so this is probably not the real
> > issue. I'll try and have a closer look later today.
> > 
> > /Tomas
> 
> Hi Tomas, thanks for taking a look.  It's quite possible my description of the problem was incorrect, or maybe my patch worked by accident.  Either way I'd certainly like to see this fixed so please let me know what you find out.

I see the problem now. It's another case of assuming OPAtom <==>
clip-wrapping. This makes it related to
https://ffmpeg.org/trac/ffmpeg/ticket/1916

Fixing this is a bit tricky. It involves parsing RP224 and extracting
all ULs defining the wrapping kinds and turning those into an
appropriate table.

This can be done by parsing RP224v10-publication-20081215.xls [1] with
libspreadsheet-read-perl. I've attached an example how to do this and
the resulting output. This output needs to be filtered further, grabbing
all lines that contain "Frame-wrapped" or "Clip-wrapped" and acting
accordingly. A clever fellow would generate some kind of prefix tree out
of it since there's a lot of redundancies. Else the resulting binary
would be needlessly large (1600 entries, 20 bytes each).

That's it for now.

(re-sent to ML)

/Tomas

[1] http://www.smpte-ra.org/mdd/RP224v10-publication-20081215.xls or
whichever version is the most recent

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rp224.pl
Type: application/x-perl
Size: 778 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130321/4a591627/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rp224.h.gz
Type: application/x-gzip
Size: 29869 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130321/4a591627/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130321/4a591627/attachment.asc>