575459 - No duration or seeking on videos loaded in their own top-level document if response does not contain Accept-Ranges: bytes

Status: RESOLVED INACTIVE

(Core :: Audio/Video: Playback, defect)

Description

[cajbir (:cajbir)]

When clicking on an Ogg video URL, or entering the URL via the URL bar, the duration is not known and seeking is disabled if the server does not send an Accept-Ranges header.

An example of such a server is Amazon S3. It supports byte range requests but does not send an Accept-Ranges header. Links to videos on Amazon that are in <video> elements in a web page work fine, showing the duration and allowing seeking. Directly accessing a video in the browser does not provide a duration or seeking support however. 

This is because the nsVideoDocument provides the channel to the video decoder - the decoder code doesn't get the chance to send a special "0-" range request and look for a 216 response code to indicate seeking support.

Steps to Reproduce:

1) Visit video in URL

What is Expected:

1) Duration
2) Seeking allowed

What actually happens:

1) No Duration
2) Cannot seek

Some discussion on ways of fixing this:

1) Instead of seeking to find the duration with the current channel, open a new channel in parallel to seek and find the duration

or

2) Check the URL extension/mime type and if it is an Ogg URL, send a "0-100" range request and check the response code.

Comment 1

[Paul Adenot (:padenot)]

This seems fixed in current nightly.

Comment 2

[u279076]

Chris, can you confirm if this bug exists on the latest Nightly?

Comment 3

[Matthew Gregan [:kinetik]]

The linked video now works because it's being served with an |Accept-Ranges: bytes| header.  The bug is still present given the correct conditions, so we'll need to find a new testcase.

Comment 4

[cajbir (:cajbir)]

Yes, Amazon recently added Accept-Ranges to their S3 service which breaks the test case.

Comment 5

[Paul Adenot (:padenot)]

I haven't found a server that behave like S3 used to behave, so I wrote a quick node-based webserver which behaves the in the same way : http://paul.cx/node/.

It replies to range request only if asked to (using a "0-" header as pointed in comment 1). If no such header is sent, it replies with a normal response (200, followed by the content).

Comment 7

[Peter Beckman]

I'm noticing that the issue is related to how Firefox handles the server response for the header "Content-Range."

RFC2616 14.16 states: "A byte-content-range-spec with a byte-range-resp-spec whose last-byte-pos value is less than its first-byte-pos value, or whose instance-length value is less than or equal to its last-byte-pos value, is invalid. The recipient of an invalid byte-content-range-spec MUST ignore it and any content transferred along with it."

For example, a request that includes -- Range: bytes=0- -- for a file of 1000 bytes should get a 206 Partial Content response with a header that states -- Content-Range: bytes 0-999/1000 -- ensuring that the instance-length is always greater than the last-byte-pos.

When a server responds with this, at least for tested Content-Type "audio/mpeg" and "audio/mp3", the HTML5 Audio object does not properly identify the duration (length) of the audio file. Thus as the audio plays, the location identifier stays pinned to the end of the progress bar. Similarly JavaScript access to audioobject.duration returns the current place location in the file, rather than the full duration.

When the Server is mis-configured to return a different Content-Range, Firefox behaves in the expected manner.

When the Server returns what should be an invalid header -- Content-Range: bytes 0-1000/1000 -- The HTML5 Audio plugin seems to correctly calculate the duration of the audio clip. However, this server response is considered not valid according to the RFC.

In posting this, I found that the "Content-Length" header was being suppressed due to a variable type conversion, and that once the Content-Length was set and sent to the browser, the RFC compliant Content-Range header succeeded.

Should the Content-Range header be able to suffice without the Content-Length header? If so, Firefox does not, at least as of version 36.0.4.

Comment 8

[Nils Ohlmeier [:drno]]

Mass closing do to inactivity.
Feel free to re-open if still needed.