Hello!

On Fri, Jun 27, 2014 at 07:26:04PM -0400, ura wrote:

> ok, thanks for clarifying.
> i just did a clean test as suggested and do indeed see the Accept-Ranges
> header being returned automatically by nginx.
>
> in doing that - the mp4 video still does not stream/pre-buffer as i am
> desiring.
>
> i accessed the test video file that is on the homepage of the video.js
> website via curl and there is no Accept-Ranges header being sent in the
> response for their file, on their server... yet their test video file
> preloads and streams correctly when i play it via the video.js player on my
> local dev machine (served via nginx).
>
> when i download their test video and play it via my same dev machine here,
> the preloading does not function.
>
> so...
> a) Accept-Ranges is not the cause of the lack of streaming here.
> b) the same file will preload on another server, yet not on mine (the
> headers being sent from the other server are not obviously different to the
> ones being sent from my own nginx server).
>
> i even downloaded a php class to correct the moov atom for the mp4 file, in
> case that was the challenge here. although some files did need to be fixed,
> the issue of the video files' moov atoms being in the wrong position, is not
> the cause of my main challenge with the pre-buffering of videos.
>
> so now i am stuck again, with no idea of what i am missing from my server to
> activate pre-buffering of video. perhaps i will message the video.js coders
> directly.

As far as I see, "video.js" isn't a player per se, but rather an
interface for HTML5 player in your browser. You may start
debugging with just a <video/> tag, without any external
interfaces. Note well that Chrome Developer Tools (especially
Network tab) are extremely helpful in debugging of such things
(or, at least, better than nothing).

I've just tested with a simple video tag and the mp4 file from the
video.js "Getting Started" page, and it seems to work fine here
with the following html code:

<video controls>
<source src="oceans-clip.mp4" type="video/mp4" />
</video>

The only problem I faced was due to OS X 10.9 network stack bug,
it seems to have problems with packet retransmission after 25 days
of uptime. As the mp4 file in question is big enough, it used to
trigger the problem when streamed from my development VM here, and
connection used to got stuck after 4M or so. And it seems that
Chrome isn't able to recover from such a problem when streaming
video using HTML5 <video/> tag (moreover, it seems to cache
unfinished responses in this case, so don't forget to clear the
cache). The problem was clearly visible in Developer Tools
though, and "netstat" confirmed the problem was somewhere in
network stack - as send queue on nginx side was full. So I
finally have to reboot my laptop to resolve this.

It's highly unlikely you are facing the same problem, but rather a
reminder that HTML5 video streaming is still quite fragile and
should be handled with care.

--
Maxim Dounin
http://nginx.org/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx