820340 - Firefox should request remaining data when server supplies only part of requested byte range

Status: RESOLVED DUPLICATE of bug 570755

(Core :: Audio/Video, defect)

Description

[softcushiontorture]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11

Steps to reproduce:

Trying to fetch a HTML5 video from a server.


Actual results:

GET /w HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0
Accept: video/webm,video/ogg,video/*;q=0.9,application/ogg;q=0.7,audio/*;q=0.6,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Range: bytes=0-
Referer: http://localhost/

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Length: 1048576
Content-Range: bytes 0-1048575/5071076
Content-Type: video/webm

When playing video using the default controls, firefox doesn't try to fetch the rest of the data. Seeking doesn't seem to be working in this scenario either.


Expected results:

Here's what happens on chromium:
GET /w HTTP/1.1
Host: localhost
Connection: keep-alive
Accept-Encoding: identity;q=1, *;q=0
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11
Accept: */*
Referer: http://localhost/
Accept-Language: en-US,en;q=0.8
Accept-Charset: UTF-8,*;q=0.5
Range: bytes=0-

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Length: 1048576
Content-Range: bytes 0-1048575/5071076
Content-Type: video/webm

GET /w HTTP/1.1
Host: localhost
Connection: keep-alive
Accept-Encoding: identity;q=1, *;q=0
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11
Accept: */*
Referer: http://localhost/
Accept-Language: en-US,en;q=0.8
Accept-Charset: UTF-8,*;q=0.5
Range: bytes=1048576-

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Length: 1048576
Content-Range: bytes 1048576-2097151/5071076
Content-Type: video/webm

(...)

And so on. 
Chromium keeps asking for additional chunks of data. So does safari. Firefox doesn't do anything even though the resource is clearly available on the server.

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

Does it work on a Nightly Build?
http://nightly.mozilla.org/

Comment 2

[softcushiontorture]

Nightly behaves the same way.

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

Did you specify the "preload" attribute on your <video> element? Without this Firefox will stop the download after downloading the first frame.

i.e.:
<video src="http://...." preload></video>

Comment 4

[softcushiontorture]

Looks like attempting to preload the video makes no difference. Firefox expects the whole file after requesting Range: bytes=0-. When the webserver refuses to just stream the whole thing and instead sends a single chunk, firefox draws a blank. Other browsers try to actively fetch the missing data.

To be honest, responding to Range: bytes=0- with only a part of requested resource is an error on part of the server, but chromium and safari at least seem not to mind.

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

Ah, so you're saying that Firefox requests "bytes=0-", but the server only returns "bytes=0-n", and Firefox doesn't trigger another request for "bytes=n-".

Comment 6

[Matthew Gregan [:kinetik]]

This sounds like a dupe of bug 570755.

Comment 7

[Chris Pearce [:cpearce (Not reading bugmail)]]

Indeed it does. Thanks for filing softcushiontorture, please reopen this bug if this doesn't look like a duplicate of bug 570755.

Comment 8

[Marques Johansson]

Just to follow up on bug 570755, I no longer work for the company I was working for when I was interested in getting Firefox to stream the video in the way Chrome did.  I didn't get the right traffic from the standards bodies either.

Another method I attempted (using node.js) was to let the browser make the full request (0-) and attempt to deliver it.  Instead of ending the request abruptly on the server I paused the server response (and the the client video controls) and then waited for heart-beat from the client to unpause the server.  I worried that this would eventually lead to a timeout or a retry (or reseek/rebuffer) by the client so I didn't pursue it too far.  Another concern was that I would have lots of open network sockets instead of being able to close them while waiting for the client to come back for more.

HLS seems to be the best modern approach.