when the last offsets in the stco atom are close to 4GB, the addition of
the moov atom size can overflow, causing corruption near the end of the
mp4 file.
this patch upgrades all stco atoms to co64 when such an edge case is
detected. in order to accomplish this, the implementation was changed to
walk the atom tree, instead of searching for the strings 'stco'/'co64'.
this was required since when an stco atom is changed to co64, its size
changes, and the sizes of all containing atoms (moov, trak, etc.) have
to be updated as well.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
1. validate the moov size before checking for cmov atom
2. avoid performing arithmetic operations on unvalidated numbers
3. verify the stco/co64 offset count does not overflow the stco/co64
atom (not only the moov atom)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The toolchain for this target is unmaintained since many years.
While it has been continuously build tested on fate, it hasn't
actually been tested at runtime since many, many years (and back
then, only a few codecs in libavcodec were tested).
So far, keeping support for it has been mostly effortless, but
the compiler does seem to have issues with dllimported data symbols,
ending up as internal compiler errors in some cases. Instead of
jumping through further hoops to work around that, just remove the
target.
Signed-off-by: Martin Storsjö <martin@martin.st>
Without this cast, the BE_32() expression is sign extended when
assigned to an uint64_t, since the uint8_t|uint8_t expression
is promoted to an int.
Also avoid undefined behaviour when left shifting an uint8_t
by 24 by casting it to an uint32_t explicitly before shifting.
Based on a patch by Michael Niedermayer.
Signed-off-by: Martin Storsjö <martin@martin.st>
These variables are assigned the return values of ftello, which
returns an off_t, which is a signed type. On errors, ftello returns
-1, thus make sure this error return value can be stored properly.
Signed-off-by: Martin Storsjö <martin@martin.st>
qt-faststart doesn't use the normal libav headers at all since
it's supposed to be a completely standalone tool, so we implement
the macro locally in this file.
Signed-off-by: Martin Storsjö <martin@martin.st>
Copying data in chunks of 1 KB is a little wasteful.
64 KB should still easily fit on the stack, so there's no need
to allocate it dynamically.
Signed-off-by: Martin Storsjö <martin@martin.st>
qt-faststart is terribly slow when the input file and the output file
are on a slow disk like a SD card. By increasing the copy_buffer from
1K to 32M I decreased the processing time on a sample file from
1600 seconds to 4 seconds. The timing difference is during 'copying
rest of file'.
S:\SD_VIDEO\PRG001>e:\utils\qt-faststart 00005.mp4 5.mp4
ftyp 0 32
free 32 8
mdat 40 13744391
moov 13744431 141848
patching stco atom...
patching stco atom...
writing ftyp atom...
writing moov atom...
copying rest of file...
Execution time: 1576.259 s
S:\SD_VIDEO\PRG001>s:\utils\qt-faststart 00005.mp4 5.mp4
ftyp 0 32
free 32 8
mdat 40 13744391
moov 13744431 141848
patching stco atom...
patching stco atom...
writing ftyp atom...
writing moov atom...
copying rest of file...
Execution time: 3.846 s
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If the atom size is 0, qt-faststart currently hangs forever while scanning
the file.
Originally committed as revision 23129 to svn://svn.ffmpeg.org/ffmpeg/trunk
Feel free to revert if you can specify a concrete case where this actually
is necessary.
Originally committed as revision 23006 to svn://svn.ffmpeg.org/ffmpeg/trunk
Carl Eugen Hoyos
erankor
Martin Storsjö
Diego Biurrun
Lou Logan
Michael Niedermayer
Jan Ehrhardt
Mans Rullgard
Baptiste Coudurier
Frank Barchard
Mike Melanson
Steve L'Homme