MP4 (H264) migrating from lighttpd to nginx

[B.R.]

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 e-healthexpert.org> wrote:

> On Sun, 29 Jan 2012 23:51:19 -0800, Michael Shadle <mike503 at gmail.com>
> wrote:
>
> > I suggest using "qt-faststart" which is a simple command line tool
> > which does this.
>
> A sort of qt-faststart howto:
>
> http://www.stoimen.com/blog/2010/11/12/how-to-make-mp4-progressive-with-qt-faststart/
>
>
> M.
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20120130/4db9ed49/attachment.html>