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

[Daniel G. Taylor]

On Sun, 2008-09-07 at 17:28 +0100, M?ns Rullg?rd wrote:
> "Daniel G. Taylor" <dan at programmer-art.org> writes:
> 
> > 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
> 
> Actually, it's being compiled every time it's run.

You're right of course, but there is no explicit compilation step
necessary from the user's perspective.

> >  * Works everywhere Python can be installed
> 
> Places where python can be installed are a (small) subset of places
> where C programs can run.

Mac OS X and every Linux distro I've used has come with Python installed
by default, and it is easy enough to install in Windows. For systems
that come with Python it is a simple matter of downloading and running
the script - no need to install compilers or learn how to compile or
anything really. This is a big deal for "average" users, especially
since Flash began supporting H.264/AAC in MP4.

If we are talking about other platforms or creating custom solutions for
video processing I agree that the C version is more useful.

> >  * 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.
> 
> Are these things that the C version can't do?  If it can't how hard
> would it be fix that?

I believe the C version is written for little-endian systems (correct me
if I'm wrong) and the comments indicate potential issues on 64-bit
platforms. It also will only handle files where the very last atom in
the file is a moov atom. If there is some other atom after the moov it
will not work (I'm not sure that this actually matters much in real life
examples but my code is written such that it will work no matter the
order of top level atoms).

These things seem fairly trivial to fix in the C code if they are
issues.

> >  * Can replace the original file if given no output filename
> 
> Does it do this using a temporary file or by in-place shuffling of
> data?

It uses a temporary file. It's basically just there for convenience
instead of having to overwrite the original yourself manually.

> > 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.
> 
> Whenever someone proposes a rewrite of an existing tool in languages
> like Python, one should first ask, what is it good for?  In this case,
> I see mainly an added dependency on a bloated interpreter and a
> tenfold increase in runtime, for no apparent improvements at all.

Just so we don't have a misunderstanding here I do not propose this tool
as replacement of the original qt-faststart.c. I merely provide this as
another option, in particular for users who have issues compiling (there
are tons of posts on many video forums regarding how to get qt-faststart
working). Replacing the original file is provided as another simple
enhancement to ease using the tool.

In terms of speed take a look at my previous mail:

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-September/052974.html

The code is written in such a way that the speed difference is
negligible (we're talking about milliseconds).

I was merely proposing that this script be included in the tools
directory as another potentially useful tool. I figured it would be a
good place for it because the code it is based on is there as well. If
anyone is really against the idea I have no problem just throwing it up
on my website and pointing people there.

Take care,
-- 
Daniel G. Taylor
http://programmer-art.org