New issue
Advanced search Search tips

Issue 919328 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Unnecessary media buffering when seeking to end

Reported by therealb...@gmail.com, Jan 5

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce the problem:
Note on other browsers: Firefox does not have this issue. Safari is N/A because it preloads the whole track it seems :(

Step 1: we need a media player that allows seeking directly to the end of the track without seeking to intermediate positions, and a very long piece of media that won't buffer all at once under normal circumstances, which supports HTTP range requests.

I've create a minimal case of a media player that works this way with some example media: http://jsfiddle.net/bqhy156n/26/

Step 2. Open the network tab before interacting with the media, with disabled cache.

Step 3. Seek to various positions in the middle of the track. Notice that a small amount of media is loaded each time without loading the whole track.

Step 4. Drag to the end of the track and release to seek directly to the end. Notice that the *entire range of media* between the previous media.currentTime and the end is loaded.

NOTE: If the previous seek position is very close to the end of the track, that range will be very short and possibly already loaded. That is why the default HTML media controls in Chrome, which seek immediately on drag, don't work well for this report.

Here is a video illustrating the issue: https://i.giphy.com/media/YiXouLAF5gQj8Uik0s/giphy.webp

What is the expected behavior?
Seeking to the very end of the track shouldn't trigger any additional media buffer, since there's nothing ahead to play.

What went wrong?
Instead we are consuming *ALL* of the media in the range between the previous currentTime and the end of the track. In the case of a very long piece of media, that can be hundreds of megabytes, which is extremely expensive especially for mobile devices. (See the video recording: https://i.giphy.com/media/YiXouLAF5gQj8Uik0s/giphy.webp)

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 71.0.3578.98  Channel: stable
OS Version: OS X 10.13.6
Flash Version:
 
Hm, the sample piece of media might be a bit much to listen to over and over while debugging so I updated the example app with a different track :) http://jsfiddle.net/bqhy156n/27/
Alas I'm realizing the new jsfiddle link I shared doesn't repro the issue well because dragging the seek bar to the end appears to seek *right before* the end, not to the very end as in the first example. So please ignore the second link. Apologies for the triple-post.
Labels: Needs-Triage-M71
Cc: santhoshkumar@chromium.org
Labels: Triaged-ET Target-73 M-73 FoundIn-74 FoundIn-71 FoundIn-72
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on reported chrome version # 71.0.3578.98 and latest chrome #73.0.3664.0 using Mac OS 10.13.6 , Ubuntu 17.10 and Windows 10 by following steps as per comment#0.

The behavior is seen from M-60. This is non regression issue hence marking it as untraiged and requesting some one from dev team to look into the issue.
Thanks

Sign in to add a comment