[FFmpeg-devel] qt-faststart bug near 4GB

Eran Kornblau eran.kornblau at kaltura.com
Thu May 31 13:11:38 EEST 2018


> 
> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf Of Eran Kornblau
> Sent: Friday, May 25, 2018 4:40 PM
> To: FFmpeg development discussions and patches <ffmpeg-devel at 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 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-qt-faststart-stco-offset-bug-fix.patch
Type: application/octet-stream
Size: 14442 bytes
Desc: 0001-qt-faststart-stco-offset-bug-fix.patch
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180531/a7147b5f/attachment.obj>


More information about the ffmpeg-devel mailing list