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

RESOLVED DUPLICATE of bug 570755

Status

()

RESOLVED DUPLICATE of bug 570755
6 years ago
6 years ago

People

(Reporter: softcushiontorture, Unassigned)

Tracking

20 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
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.
Component: Untriaged → Video/Audio
Product: Firefox → Core
Does it work on a Nightly Build?
http://nightly.mozilla.org/
(Reporter)

Updated

6 years ago
Version: 17 Branch → 20 Branch
(Reporter)

Comment 2

6 years ago
Nightly behaves the same way.
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>
(Reporter)

Comment 4

6 years ago
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.
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-".
Summary: Firefox does not try to fetch additional data when playing HTML5 video → Firefox should request remaining data when server supplies only part of requested byte range
This sounds like a dupe of bug 570755.
Indeed it does. Thanks for filing softcushiontorture, please reopen this bug if this doesn't look like a duplicate of bug 570755.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 570755

Comment 8

6 years ago
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.
You need to log in before you can comment on or make changes to this bug.