5

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.

John Hunt
  • 4,265
  • 8
  • 45
  • 59
  • Note, I'd rather not use jwplayer as it's not open source. – John Hunt Oct 09 '12 at 13:30
  • Additional: In Chrome under the network tab of dev tools I get two requests for the video file, the first has status of pending, the second has status of cancelled, both type pending but the cancelled status one is in red. Both sizes are 13bytes, the time on the second is 551ms. – John Hunt Oct 09 '12 at 13:37

3 Answers3

9

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.

Jonny Roller
  • 106
  • 4
  • 1
    It's true, chrome fails to deliver videos while others (Firefox and Safari) do it perfectly. – Jayr Motta May 15 '13 at 16:30
  • 1
    There is a way to change this response status in apache instead of creating an app to intercept the stream and change the status code? – Jayr Motta May 16 '13 at 15:57
  • 1
    Wow thanks for the answer, I was running into exactly the same thing writing my own http server on android. Returning 200 instead of 216 indeed does fix it! – Maks Oct 03 '13 at 06:15
1

Having just run into this with Chrome, it seems that you need to ensure that the Content-Range header is set by your server in the response.

From http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html:

Examples of byte-content-range-spec values, assuming that the entity contains a total of 1234 bytes:

      . The first 500 bytes:
       bytes 0-499/1234
      . The second 500 bytes:
       bytes 500-999/1234
      . All except for the first 500 bytes:
       bytes 500-1233/1234
      . The last 500 bytes:
       bytes 734-1233/1234
0

Might be a problem on your apache... presumably you are using apache given the tag.

Have you added the mime types to apache?

e.g.

AddType video/mp4 mp4

AddType video/mp4 m4v

Also check that gzip is turned off for for the media... it is already compressed... and don't gzip Jplayer.swf.

Can you post your apache config? Are you using any streaming modules such as this?

Cheers Robin

EDIT

o and also you might want to accept-ranges bytes in apache. If you look closesly at the two links you are serving a 200 and they are serving a 206 partial data.

leek
  • 11,803
  • 8
  • 45
  • 61
Robin Rieger
  • 1,204
  • 1
  • 16
  • 37