MP4 (H264) migrating from lighttpd to nginx

Ondrej Jombik jombik at
Mon Jan 30 16:09:19 UTC 2012

Sometimes it happens that you are working under light, and that light is
so bright, so you are unable to see obvious things. This happened to me.

Yes, now my initial question looks a bit strange, but thanks to asking
I have at least two options how to deal with the issue.

According to Igor, moving index to the beginning of the file should be
better from the performance point of view. Since we are migrating not
only from lighttpd to nginx, but also to new storage, I will put this
"recoding" into migration batch and we will have nice MP4 files at the end.

Thanks again and... nginx mp4 module rocks! :)


On Mon, 30 Jan 2012, B.R. wrote:

> Hi again,
> I am glad a little Googling + some basic reading made me able to answer
> your expert question! :oP
> I am still no expert, but from what I read on the link I gave you, there is
> a link to how to prepare files to be served in streaming.
> It was mentioned that if a file is not prepared as it should be (metadata
> at the start of files), the consequence was the calculation of this missing
> metadata CPU & I/O overhead, including extra harddisk use... which is bad
> for performance! They even not mention the cache faults...
> It is said that the metadata must be the first thing read in a file which
> is read sequentially from the beginning. So, if your metadata is at the
> end... I let you finish that ^^
> Nginx, like lighttpd, is able to do that on its own but that kills
> performance, so the better the files are prepared, the less you will use
> resources on your server.
> However, as Igor mentioned, it is only about moving metadata, not encoding
> the whole files again, which is a simpler task to do.
> If you wish to process your files and that you have a lot of them, maybe it
> is not worth it to do so with a unique and long shot.
> Maybe you could make your files served through some checking server-sided
> script, which will serve the data from the current file and concurrently
> regenerate a new well-made file for future requests?
> That's maybe not the best solution but that would allow to start converting
> regularly served files first. Of course it would be a temporary one...
> ---
> *B. R.*
> On Mon, Jan 30, 2012 at 04:23, Mark Alan <varia at> wrote:
>> On Sun, 29 Jan 2012 23:51:19 -0800, Michael Shadle <mike503 at>
>> wrote:
>>> I suggest using "qt-faststart" which is a simple command line tool
>>> which does this.
>> A sort of qt-faststart howto:

Platon Technologies s.r.o., Hlavna 3, Sala SK-92701
+421 903 PLATON - info at -

More information about the nginx mailing list