[FFmpeg-devel] RFC qt-faststart Implemented in Python

Daniel G. Taylor dan
Thu Sep 4 14:45:05 CEST 2008

On Wed, 2008-09-03 at 23:14 -0700, Mike Melanson wrote:
> Daniel G. Taylor wrote:
> > Hello,
> > 
> > I have recently reimplemented qt-faststart.c in Python. It is attached
> > to this message. It is nearly as fast as the C version and has some
> > useful features:
> > 
> >  * No compilation needed
> >  * Works everywhere Python can be installed
> >  * Handles both 32-bit (stco) and 64-bit (co64) atoms (regardless of 
> >    whether the underlying system is 32/64-bit, big/little endian, etc)
> >  * Handles any file where the mdat atom is before the moov atom, and
> >    preserves the order of atoms in the file after moving the moov atom.
> >  * Can replace the original file if given no output filename
> > 
> > Since others may find this useful I'm posting it here and asking if it
> > can be included in the tools directory like qt-faststart.c is.
> > 
> > Any comments are appreciated.
> Looks nice. Does it really strictly on Python's standard library?

Yes. It requires the os, shutil, struct, sys, tempfile, optparse, and
StringIO modules, all of which ship with Python as of version 2.3. Same
with generators (which I use to find the stco or co64 atoms).

Also, as a quick comparison (taking into account buffering in memory, so
the test was run a bunch of times):

Full length movie (1 GiB file with 11757 chunk offsets):
    qt-faststart.c:  15.9 seconds
    qt-faststart.py: 16.1 seconds

Small video (10 MiB file with 17394 chunk offsets):
    qt-faststart.c:  0.1 seconds
    qt-faststart.py: 0.2 seconds

One thing to note though is the python version does use more memory
since the interpreter must be loaded, the script run, and while copying
I set my default buffer size when copying to 8192 bytes instead of the C
version's 1024, but that's hardly anything anyway.

I also thought about trying to use e.g. psyco to speed things up but it
incurs quite a startup time penalty and isn't included with Python so I
decided against it for maximum compatibility.

Take care,
Daniel G. Taylor

More information about the ffmpeg-devel mailing list