I've set up a bit of a test site.. I'm trying to implement an HTML5 video to play on a site I'm developing and I want to use jplayer so that it falls back to an swf file if html5 video is not supported.
http://dev.johnhunt.com.au/ is what I have so far. It works fine if I provide http://www.jplayer.org/video/m4v/Big_Buck_Bunny_Trailer_480x270_h264aac.m4v for the video, however if I host it on my own server it simply never starts playing.
The mime type is definitely correct, video/m4v. Charles proxy says:
Client closed connection before receiving entire response
Infact, here's the entire request:
GET /Big_Buck_Bunny_Trailer_480x270_h264aac.m4v HTTP/1.1
Host dev.johnhunt.com.au
Cache-Control no-cache
Accept-Encoding identity;q=1, *;q=0
Pragma no-cache
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4
Accept */*
Referer http://dev.johnhunt.com.au/
Accept-Language en-US,en;q=0.8
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie __utma=120066461.1007786402.1349773481.1349773481.1349786970.2; __utmb=120066461.1.10.1349786970; __utmc=120066461; __utmz=120066461.1349773481.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Range bytes=0-
And response:
Some binary data (maybe 3 or 4kbytes long)
Which looks ok. I assume the 'client' is my chrome browser.. why is it giving up? How can I fix this? It's driving me mad as I can't find anything on google :(
When I use the m4v file on jplayer.org this is the request:
GET /video/m4v/Big_Buck_Bunny_Trailer_480x270_h264aac.m4v HTTP/1.1
Host www.jplayer.org
Cache-Control no-cache
Accept-Encoding identity;q=1, *;q=0
Pragma no-cache
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4
Accept */*
Referer http://dev.johnhunt.com.au/
Accept-Language en-US,en;q=0.8
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie __utma=24821473.325705124.1349773077.1349773077.1349773077.1; __utmc=24821473; __utmz=24821473.1349773077.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)
Range bytes=0-
Response:
Lots of binary data (very long.. working)
Cheers, John.
I've found that when the Chrome browser sends a "Range: bytes=0-" request, you should NOT respond with a "206 Partial Content" response. To get Chrome to handle the data properly, you need to send back a "200 OK" header.
I don't know if this is correct according to the specs but it gets Chrome to work and does not appear to break other browsers.