Unnecessary media buffering when seeking to end
Reported by
therealb...@gmail.com,
Jan 5
|
|||
Issue descriptionUserAgent: 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:
,
Jan 5
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.
,
Jan 6
,
Jan 7
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 |
|||
Comment 1 by therealb...@gmail.com
, Jan 5