> > -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Eran > Kornblau > Sent: Friday, May 25, 2018 4:40 PM > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> > Subject: [FFmpeg-devel] qt-faststart bug near 4GB > > Hi all, > > We encountered a rather extreme edge case with qt-faststart - we transcoded > some video with ffmpeg, and the offset of the last video frame in the > resulting mp4 was slightly less than 4GB. > Since it was less than 4GB, ffmpeg used an 'stco' atom and not a 'co64' atom. > When we ran qt-faststart on this file, it added the moov atom size to all > offsets in the 'stco' atom, causing an overflow in the offsets of the frames > close to the end of the file. The end of the video was therefore corrupt and > could not be played. > I think the solution here is to 'upgrade' the 'stco' atom to 'co64' if such > an edge case happens. However, looking at the code of qt-faststart, I see > that it doesn't actually parse the atom tree, but rather looks for the > strings 'stco' / 'co64'. Changing 'stco' to 'co64' requires updating the size > of all the atom in which it's contained (moov, trak, mdia etc.) Therefore, > such a change would probably be more of a rewrite of this utility than a > patch, so wanted to check whether anyone has any thoughts on this before I > start writing... > Attaching the patch for this issue. As expected, it required significant changes... hope you will like it :)
Thanks! Eran
0001-qt-faststart-stco-offset-bug-fix.patch
Description: 0001-qt-faststart-stco-offset-bug-fix.patch
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
