New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 697112 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 689989
Owner:
Last visit > 30 days ago
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Chrome Video loop Bandwidth Leak

Reported by buddu.sk...@gmail.com, Feb 28 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.74 Safari/537.36

Example URL:
https://jsfiddle.net/abidCharlotte49er/qdw41j1j/

Steps to reproduce the problem:
1. Run any website that has HTML video tag that is set to loop
2. Open Developer tools -> Network tab -> Media
3. Please note the video downloads over and over instead of grabbing it from the Device Cache 

What is the expected behavior?
Once the Video is downloaded we should loop it from the Cache why do we request the video again and download it over and over

What went wrong?
HTML Video when set to loo it downloads the video over and over instead of playing from Cache. If images are cached why can't we cache videos. I have confirmed "Disable Chache" checkbox is unchecked while testing this. Thank You  

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes Not sure 

Does this work in other browsers? Yes

Chrome version: 57.0.2987.74 and 56.0.2924.87   Channel: stable
OS Version: Windows 7, 10 
Flash Version:

 
I can confirm this is working on Chrome Version 54.0.2840.71 but not on 55, 56, 57 Builds. It has been broken since December 2016 and it looks like no one noticed this Bandwidth leak.  
ChromeVideoLoop.png
171 KB View Download
Chrome54.0.2840.71.png
101 KB View Download
Cc: hdodda@chromium.org
Labels: -Type-Bug -Pri-2 hasbisect-per-revision M-58 OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: hubbe@chromium.org
Status: Assigned (was: Unconfirmed)
Using the per-revision bisect providing the bisect results,
Good build: 55.0.2862.0 (Revision: 419063).
Bad build: 55.0.2863.0 (Revision: 419330).

You are probably looking for a change made after 419263 (known good), but no later than 419264 (first known bad).

CHANGELOG URL:

The script might not always return single CL as suspectas some perf builds might get missing due to failure.

 https://chromium.googlesource.com/chromium/src/+log/343264820eb254bdab3dbeef0082e8e1bb307532..fd30799f6f8a7d1366d97693b72b0b20be94d5c0

From the CL above, assigning the issue to the concern owner 

@hubbe - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Review-Url: https://codereview.chromium.org/2338963002

Note : Issue is not seen on latest canary M58 #58.0.3026.0 

Thanks!

Comment 3 by hubbe@chromium.org, Mar 1 2017

Mergedinto: 689989
Status: Duplicate (was: Assigned)

Sign in to add a comment