[FFmpeg-devel] [Bulk] [PATCH] avformat/mxfdec: dont truncate packets

[Michael Niedermayer]

On Thu, Jan 30, 2014 at 07:45:19PM +0100, Tomas Härdin wrote:
> On Thu, 2014-01-30 at 02:39 +0100, Michael Niedermayer wrote:
> > On Wed, Jan 29, 2014 at 10:20:48AM +0100, Tomas Härdin wrote:
> > > On Tue, 2013-11-05 at 07:57 +0000, Tim Nicholson wrote:
> > > > On 24/10/13 20:28, Michael Niedermayer wrote:
> > > > > Fixes Ticket2776
> > > > > 
> > > > > Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
> > > > > ---
> > > > >  libavformat/mxfdec.c |    1 -
> > > > >  1 file changed, 1 deletion(-)
> > > > > 
> > > > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > > > index d0cbeea..59e5c0d 100644
> > > > > --- a/libavformat/mxfdec.c
> > > > > +++ b/libavformat/mxfdec.c
> > > > > @@ -2285,7 +2285,6 @@ static int mxf_read_packet_old(AVFormatContext *s, AVPacket *pkt)
> > > > >                                        "KLV for edit unit %i extending into "
> > > > >                                        "next edit unit",
> > > > >                                        mxf->current_edit_unit);
> > > > > -                klv.length = next_ofs - avio_tell(s->pb);
> > > > >              }
> > > > >  
> > > > >              /* check for 8 channels AES3 element */
> > > > > 
> > > > 
> > > > Sorry for a very late review, but I have been snowed under (with a
> > > > project using ffv1 v3 you may be pleased to hear) and after a quick
> > > > glance it didn't feel right and I wanted to delve further.
> > > > 
> > > > We go to the bother of performing a test to trap (an admittdedly
> > > > unusual) case, and then if it happens do not introduce the safety net to
> > > > avoid an error. It would be better to work out why a false positive is
> > > > occuring with the sample and fix that, otherwise we will reintroduce the
> > > > issue this segment of code was trying to fix.
> > > > 
> > > > Does Tomas have a view? the original code to trap the misreading of OP
> > > > Atom was his.
> > > 
> > > Sorry for the extremely late reply. But yes, that piece of code is there
> > > to deal with certain bad files. I don't remember if we/I have samples
> > > for it, but I trust my old self put it there for good reasons.
> > > 
> > > As for a proper fix, my MXF is a bit rusty. But I think this ties into a
> > > thing I had in mind a while back, which was to introduce a huge table
> > > mapping all EssenceContainer ULs to the corresponding wrapping kind
> > > (relying on byte 15 of the UL is incorrect). I don't think relying on
> > > OperationalPattern is enough to determine if the file is clip wrapped or
> > > frame wrapped, and the MXF specs are vague on this matter (as usual).
> > > Mistaking clip wrapped essence for being frame wrapped is what that
> > > piece of code is about.
> > > 
> > 
> > > I think I put some random unfinished code on this mailing list for
> > > generating the EssenceContainer -> WrappingKind tables described above.
> > > The problem then is that they will grow the binary by about half a
> > > megabyte..
> > 
> > if the tables can be generated and the generation code is smaller
> > than the tables then the space problem should be avoidable
> 
> IIRC the tables are generated from Excel files via a perl script, so
> that's runtime generation is not going to work

adding 500kb for this doesnt sound very nice :(

is there no other way to find the wraping kind,
without reling on the ULs ?
or am i missing something here

also if someone has samples that cover the relevant cases so this
can be tested by whoever tries to implement it. That would be very
welcome too

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140130/30219223/attachment.asc>