[FFmpeg-devel] [PATCH] qt-faststart: Abort scanning the input file if a bad atom is found

Martin Storsjö martin
Thu May 13 21:23:26 CEST 2010


On Sun, 9 May 2010, Martin Storsj? wrote:

> On Sun, 2 May 2010, Martin Storsj? wrote:
> 
> > On Sat, 1 May 2010, Martin Storsj? wrote:
> > 
> > > On Fri, 30 Apr 2010, Baptiste Coudurier wrote:
> > > 
> > > > On 04/30/2010 06:42 AM, Daniel G. Taylor wrote:
> > > > > On 04/30/2010 06:36 AM, Martin Storsj? wrote:
> > > > > > The attached patch avoids hanging forever if encountering atoms of
> > > > > > size 0.
> > > > > > (Such files aren't valid, of course, but it's better to abort the
> > > > > > application instead of looping infinitely.)
> > > > > 
> > > > > There are actually some valid files that seem to end with an mdat atom
> > > > > of zero size, and this patch would allow qt-faststart to process them. I
> > > > > applied a similar patch to my Python port a while back here:
> > > > > 
> > > > > http://github.com/danielgtaylor/qtfaststart/blob/master/qtfaststart.py
> > > > > 
> > > > > In case of those files where the mdat size is zero but the data is there
> > > > > you may want to break and just read until the end of the file rather
> > > > > than exiting.
> > > > 
> > > > Indeed, mdat 0 size is allowed but the atom must be the last in the file.
> > > > 
> > > > So aborting on atom_size < 8 is not correct in that case.
> > > 
> > > Ok, so would doing break; be correct then? We can't continue scanning past 
> > > such an atom anyway, but we'd get the "last atom in file was not a moov 
> > > atom" instead. And currently such a file would hang the application.
> > 
> > Is this better, then?
> 
> Ping

Ok'd by Baptiste on irc, applied.

// Martin



More information about the ffmpeg-devel mailing list