Klient zamyka połączenie podczas przesyłania strumieniowego m4v z apache do chrome z jplayerem

Question

Przygotowałem trochę strony testowej. Próbuję zaimplementować wideo HTML5 do gry na stronie, którą rozwijam i chcę użyj jplayera, aby powrócił do pliku SWF, jeśli wideo HTML5 nie jest obsługiwane.

http://dev.johnhunt.com.au/ jest tym, co do tej pory miałem. Działa to dobrze, jeśli dostarczę film wideo w postaci http://www.jplayer.org/video/m4v/Big_Buck_Bunny_Trailer_480x270_h264aac.m4v, jednak jeśli hostuję go na własnym serwerze, po prostu nigdy nie zacznie grać.

Typ MIME jest zdecydowanie poprawny, wideo/m4v. Charles proxy mówi:

Client closed connection before receiving entire response 

Rzeczywiście, oto cała prośba:

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- 

I odpowiedź:

Some binary data (maybe 3 or 4kbytes long) 

Która wygląda ok. Zakładam, że "klient" to moja przeglądarka Chrome. Dlaczego się poddaje? Jak mogę to naprawić? To doprowadza mnie do szału, bo nie mogę znaleźć nic na google :(

Gdy używam plik m4v na jplayer.org to żądanie:

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) 

Pozdrawiam, John.,

Answer 1

Odkryłem, że gdy przeglądarka Chrome wysyła żądanie "Zakres: bajty = 0-", NIE POWINIEN odpowiedzieć odpowiedzią "206 Częściowa zawartość". Aby Chrome poprawnie obsługiwał dane, musisz odesłać nagłówek "200 OK".

Nie wiem, czy jest to zgodne ze specyfikacją, ale powoduje, że Chrome działa i wygląda na to, że nie łamie innych przeglądarek.

Answer 2

Może być problemem na twoim apache ... prawdopodobnie używasz Apache'a z przypisanym znacznikiem.

Czy dodałeś typy mime do apache?

np.

AddType video/mp4 mp4

AddType video/mp4 m4v

również sprawdzić, czy gzip jest wyłączone dla mediów ... to jest już skompresowany ... i nie gzip JPlayer. swf.

Czy możesz wysłać swoją konfigurację apache? Używasz żadnych modułów, takich jak strumieniowe this?

Cheers Robin

EDIT

oi również może chcesz zaakceptować zakresów bajtów w apache. Jeśli przyjrzysz się bliżej dwóm łączom, z których korzystasz, otrzymujesz 200 częściowych danych.

Answer 3

Po uruchomieniu tego w Chrome wydaje się, że w odpowiedzi musisz ustawić nagłówek Content-Range na serwerze.

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

Przykłady wartości bajt treści Zakres spec, zakładając, że jednostka zawiera łącznie 1234 bajtów:

 
     . 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