It is great that MP4 module came out. So we decided to migrate our video
streaming servers to nginx. In fact those are our last non-nginx
webservers (not counting IIS).
However we have some troubles. In our Flash player, MP4 video starts
play only after it is completelly loaded. I thought there is problem
with player, so I tried open-source flowplayer and it was the same.
So I thought that there is problem with nginx HTTP response. I compared
it completelly to lighttpd response, and made them exactly same. I even
changed the nginx server name to “lighttpd” (source recompilation was
needed), added headers like “X-Mod-H264-Streaming”, but still no luck.
When serving video through lighttpd, it starts play immediately.
When serving through nginx, it starts play only after it is fully
loaded.
However requests for partial files like video.mp4?start=32.33 works well
with nginx. I think there is problem with initial request (the one
without “start” parameter).
I’m stuck. Any ideas what else should be checked?
Any advice would be appreciated. Thanks.
Ondrej
–
Ondrej JOMBIK
Platon Technologies s.r.o., Hlavna 3, Sala SK-92701
+421 903 PLATON - [email protected] - http://platon.org
I am no expert in streaming, but I read from the
ngx_http_mp4_modulehttp://nginx.org/en/docs/http/ngx_http_mp4_module.htmlpage
a special request of ‘start=0’ would transfer metadata.
Maybe without it, the file would simply be considered as a normal file
and
then served completely before being able to be read ?
My 2 cents…
B. R.
Thanks B.R., you are exactly right, after appending “?start=0” video
starts to play immediatelly.
I also discovered that our MP4 files are encoded with index at the end
of file. lighttpd was silently moving this index (moov) to the
beginning.
That raises question for some nginx performance guru:
What is better: recode all the MP4 files (thousands of thousands) and
move index to the beginning or simply use “?start=0” parameter?
I feel that recoding may save us some memory during future request
processing, because with “?start=0” nginx must at least see the end of
file and fetch the index.
Any opinion would be welcome. I have no problem to recode/reindex milion
files, but it has to have some meaning first 
Thanks
Ondrej
On Mon, 30 Jan 2012, B.R. wrote:
So I thought that there is problem with nginx HTTP response. I compared
without “start” parameter).
_____________**
nginx mailing list
[email protected]
http://mailman.nginx.org/**mailman/listinfo/nginxhttp://mailman.nginx.org/mailman/listinfo/nginx
–
Ondrej JOMBIK
Platon Technologies s.r.o., Hlavna 3, Sala SK-92701
+421 903 PLATON - [email protected] - http://platon.org
Hello!
On Mon, Jan 30, 2012 at 04:09:33AM +0100, Ondrej Jombik wrote:
changed the nginx server name to “lighttpd” (source recompilation was
I’m stuck. Any ideas what else should be checked?
Any advice would be appreciated. Thanks.
On initial request nginx returns original file, and if moov atom
with metadata goes after mdat (one with media data) you’ll see
“video starts after loading” problem. Recoding files to place
moov atom first will solve it.
Maxim D.
I suggest using “qt-faststart” which is a simple command line tool which
does this.
On Mon, Jan 30, 2012 at 08:08:13AM +0100, Ondrej Jombik wrote:
move index to the beginning or simply use “?start=0” parameter?
I feel that recoding may save us some memory during future request
processing, because with “?start=0” nginx must at least see the end of
file and fetch the index.
Any opinion would be welcome. I have no problem to recode/reindex milion
files, but it has to have some meaning first 
From perfomance point of view it’s better to move the index to the
beginning.
However, you do not need to recode the files, but just to move the
index.
–
Igor S.
On Sun, 29 Jan 2012 23:51:19 -0800, Michael S. [email protected]
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.
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.
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! 
Ondrej
On Mon, 30 Jan 2012, B.R. wrote:
for performance! They even not mention the cache faults…
If you wish to process your files and that you have a lot of them, maybe it
On Mon, Jan 30, 2012 at 04:23, Mark A. [email protected] wrote:
On Sun, 29 Jan 2012 23:51:19 -0800, Michael S. [email protected]
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/
–
Ondrej JOMBIK
Platon Technologies s.r.o., Hlavna 3, Sala SK-92701
+421 903 PLATON - [email protected] - http://platon.org