1142084 - Video seeking fires a lot of small requests before starting to play again

Status: RESOLVED WORKSFORME

(Core :: Audio/Video, defect)

Description

[Jakub]

Attachment: firefox.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.76 Safari/537.36

Steps to reproduce:

Open any video from vimeo.com (or other website streaming mp4 file with html5 player but not youtube). Start a video and seek in unbuffered area. In developer tools open network tab and see how many requests are created after one seek. Repeat few times to get a good overview.


Actual results:

After some seeks you create up to around 35 small requests to mp4 file untill you start playing the video (attached screenshot). Sometimes it's less, but most of the time you get more then one additional request. It's wokring like this since version 35, before it worked properly (checked ff 33 a 34).


Expected results:

After seeking one additional request is created and old request is cancelled.

Comment 1

[Nickolay_Ponomarev]

I can reproduce on https://vimeo.com/channels/staffpicks/54589245 using both 36.0.3 and current nightly on OS X.

See also bug 1145608 and bug 1142455.

Comment 2

[Foliovision]

Same problem here (Firefox 37.0.1 on OS X and Windows 7). Firefox fires a lot of HTTP 206 requests when random seekinging in an MP4.

It seems to be worse if the MP4 file is slow to download - Firefox fires the HTTP 206 requests and then within around 1 second fires another one with a slightly different range and so on and on.

Chrome has no issues with this - even if the media download is slow, it only creates a one HTTP 206 request which then waits for the data.

Comment 3

[thomas.guyard]

Same problem on 38.0.5 windows. 
I can't reproduce this bug on linux.

With big video (1hour, 1080p, > 1Go) it makes seeking impossible.
Maybe because the server can't handle hundreds of small requests...

Comment 4

[deheleri]

Same problem on Firefox 38.0.5 Windows 7 64-bit.

The issue only happens if there is an audio stream in the file. See this bug report:
https://bugzilla.mozilla.org/show_bug.cgi?id=1142455

Here is another video where it happens. Open dev console and watch the network requests go crazy with 206 partial content requests when you seek near the end of the file:
http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_1080p_30fps_normal.mp4

Comment 5

[Jean-Yves Avenard [:jya]]

When seeking you can only first seek to the keyframe located before your seeking point ; after that, you must decode all frames (and drop them) until you reach the frame you actually need.

This video has keyframes every 128 frames. So seeing 60 requests after a seek is perfectly normal as you may have to retrieve up to 128 frames before you get to your seeking point.

It's a timing issue really, when you start seeking the data could be entirely into the cache.

Comment 6

[Foliovision]

I get that it has to download a bigger part of the video, but why use another HTTP request for that? Other browsers don't do it that way, you simply wait longer for the seeking to finish.

Comment 7

[Jean-Yves Avenard [:jya]]

because bug 1142455.

Right now, if you're attempting to read at two different positions which are more than 32kB appart; it will perform a range-request rather than simply read more at once.

We're changing this value to 1MiB instead.

So instead of small range-request, you will see a single continuous request.