I configured streaming with ngx_http_mp4_module .
I use optimized mp4 with moov atoms located at the beginning of the
file.
Streaming really works, BUT.
In comparison with flv its takes much more time to seek through movie.
For example i want to move to position - 00:05:00, it takes about half
second or even 2 secs to finish.
When i used flv - it was instant, also seeking mp4 videos on youtube is
instant too.
I noticed that player shows downloading status during this delay , so i
checked tcpdump and found out, that
nginx sends moov atom to player EVERY time. Moov data is about 300KB,
so only after downloading it , player starts getting real video.
I understand why player needs MOOV data, when send first GET without
“start” parameter.
But i really dont understand why it needs same MOOV data later, when
sends request like GET /file.mp4?start=300
Can you clear out these issue for me?
May be i misconfigured something ?
On Mon, Mar 05, 2012 at 01:53:00AM -0500, dagr wrote:
When i used flv - it was instant, also seeking mp4 videos on youtube is
But i really dont understand why it needs same MOOV data later, when
sends request like GET /file.mp4?start=300
Can you clear out these issue for me?
May be i misconfigured something ?
nginx-1.0.12
This is expected behaviour. This is the way, how Flash players work:
they require complete MP3 stream with MOOV/MDAT on each request.
This is the reason why ngx_http_mp4_module exists at all. If the players
were able play without MOOV data on each request using MOOV data from
the first request, there was no need in ngx_http_mp4_module. The module
adjusts MOOV data for each request. If you seek MP4 file near the end,
the MOOV data will be lesser.
So how does YouTube manage to get 2 hour videos to start playing
instantly (1 second)… with nginx it takes me 10 seconds for a 2 hour
video to start playing.
That was back in 2008, they didn’t have 2 hour long videos. But what I
was talking about what regarding the technology, lighttpd and nginx both
do pseudo streaming. The moov atom is about 5 MB so it takes about 10
seconds to download that before playing the video. Is there some
technique to start playing the video after partial download of the moov
atom? Or is it possible to cache the moov atom into memory for faster
retrieval?
You can split the big movie file into small pieces, thus you have
smaller index for each small movie file.
In the player, when current part is about to end, load next part, when
current part is over, play the next part. So the movie is played
seamlessly, you save network traffics, and your users feel better. You
need to modify your movie player, but it is not a very hard work.
Be caution: you must split your movie file at offsets of key-frame.
–
191919
Le mercredi, avril 18, 2012 à 9:23 AM, ragivan a écrit :
Do you know a tool for doing this? Something that will work on a unix
system. Also, what if the user wants to jump to the end of the movie? I
suppose that won’t be possible as the user must click to the end of each
segment until reaching the last segment.
191919 Wrote:
That was back in 2008, they didn’t have 2 hour
into memory for faster
On Tue, Apr 17, 2012 at 09:23:13PM -0400, ragivan wrote:
That was back in 2008, they didn’t have 2 hour long videos. But what I
was talking about what regarding the technology, lighttpd and nginx both
do pseudo streaming. The moov atom is about 5 MB so it takes about 10
seconds to download that before playing the video. Is there some
technique to start playing the video after partial download of the moov
atom? Or is it possible to cache the moov atom into memory for faster
retrieval?
I’ve just tried to watch 3 YouTube movies in Firefox 11 with Flash
installed
and discovered using LiveHTTPHeaders that these movies are in FLV
format.
Using this format player is smart enough to request just a file offset
but not movie time and it does not need movie metadata such as MOOV
atom.
It need just a small static 13-bytes FLV header: http://nginx.org/en/docs/http/ngx_http_flv_module.html
If you try to download youtube movie (any movie which i tried so far)
with Download Master - then if you download 720p or higher, you ll get
MP4 file , not FLV. Download Master emulates flash player to retrieve
video , so it looks like flash player in resolutions 720p 1080p plays
mp4 (not flv) too (may be i wrong).
AFAIK youtube stores video under 720p as flv and >=720p as mp4 and
another batch of mp4 files for ipads which are encoded with main
profile, not high.
By the way, i was not able to find on youtube 720p MP4 files longer
than 20 mins ( moov data is not huge), so their smooth playing doesnt
look very strange.
Anyway - ipads CAN seek smoothly mp4 files without all this shit with
moov data.
And Adobe flash player - doesnt - very strange.
I wrote such a tool which generates mp4 file-series, it is simple if you
are familiar with libgpac.
You have to keep an array which maps time to file indexes, when a user
wants to seek to a specific position, just convert the timestamp (e.g.
01:15:14) to file index (movie_2314_segment_519.mp4) then request it
from the server.
You can also use FLVs which contain H264 and AAC if Flash Player is your
only client.
–
191919
Le mercredi, avril 18, 2012 à 2:29 PM, ragivan a écrit :
Anyway - ipads CAN seek smoothly mp4 files without all this shit with> moov
data.
Ipads don’t use flash with pseudostreaming, but html5/native apps,which
probably use HTTP Range requests instead.
If you embed MP4 content with html5 and play it in chrome or safari(they
have html5 with h264 support), you will probably see similarperformance.