karel.braeckman@ Thanks for the issue.

Tested this issue on Windows 10 and Mac OS 10.12.6 on the reported version 64.0.3282.167 and latest Canary 66.0.3350.0 and unable to reproduce the issue by following the steps given in the original comment.

Can observe that huge amount of requests are not fired in the Network tab on opening the given html page and playing the video
Attached is the screen cast for reference.

Request you to retry the issue on a new chrome profile without any flags/extensions and update the thread with the observations.

Thanks..

Deleted: 814328.mp4 1.6 MB

	814328.mp4 1.6 MB View Download

Hi Susan,

Thanks for looking into this. Please note that the problem occurs when the player is paused (not playing). Can you try again, but leave the player paused. Then click somewhere in the middle of the scrubber bar to seek to halfway the video.

I also created a new profile and reproduced the issue, see attached screencast.

Deleted: 2018-02-22_09-50-35.mp4 3.1 MB

	2018-02-22_09-50-35.mp4 3.1 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

karel.braeckman@ Thanks for the feedback.

Tested this issue on Mac OS 10.12.6, Windows 10 and Ubuntu 14.04 on the latest Stable 64.0.3282.186 and Canary 66.0.3352.0 and able to reproduce the issue as per comment #3.

Bisect Information:
===================
Good Build: 64.0.3250.0 (Revision - 511680)
Bad Build : 64.0.3251.0 (Revision - 512036)

On executing the per-revision bisect script, below is the Changelog URL:

https://chromium.googlesource.com/chromium/src/+log/69fc8466a5a1b6ff4e9503c1bf7105c19e12e1f1..ba416ac0e7132ccefc1f3e3a8517acae5370a34c

From the above Changelog, suspecting the below change:
Reviewed-on: https://chromium-review.googlesource.com/731675

apacible@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.

Adding ReleaseBlock-Stable as this is a recent regression. Please feel to remove the same if it is not applicable.

Thanks.

M65 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Merge has to happen latest by 1:00 PM PT Tuesday (02/27/18) in order to make it to last M65 beta release next week. Thank you.

Ok, so here's what's going:

1. We're changing the default preloading to "metadata" instead of "auto" which means that we load less data when we start a video.
2. Since we still load a couple of frames of video, we need the data for these frames. This ends up causing some extra seeks as the data we need is slightly spread out. Depending on the video, this may be a little or a lot.
3. When we start playing the video, we always change the preload mode to auto. So once the video has been played, the behavior changes.
4. If you seek *without* playing the video, the behaviour from (2) repeats.

Ultimately, having preload=metadata generate more requests is probably not a good thing, even if those requests actually end up reading less data than preload=auto, I will dig a little deeper to see if there something we can do about that.

Alternatively (additionally?), we may consider switching to preload=auto whenever whenever the user initiates a seek.

Hmm, it seems that the problem with (2) is that WMPI calls HaveEnoughData even though some parts of the pipeline aren't done reading data. The MultiBufferData source doesn't expect more reads, so it closes the connection, and when more reads come in it has to re-open the connection.

For preload=auto, this is a pretty minor problem, as the extra reads can come out of the preload.

Probably we can take the video out of preload metadata (at least internally) as soon as a user interacts with it.

The problem occurs on the initial preload as well.

Have some sort of fall after last read instead of closing the connection immediately? 

Gentle ping !!
It is marked as stable blocker for M65,Please merge fix ASAP as M65 stable promotion is scheduled today night.

Thanks..!

This should not be a Stable blocker IMO as it's not breaking anything and will only affect <video> with no `preload` set. The behaviour already exist if a website sets `preload` to `metadata` manually too.

Regarding how to fix it, I'm not entirely certain what WMPI does when preload is set to metadata but it seems slightly surprising to me that it doesn't try to preload more than the current frame. The spec doesn't forbid the UA to do more and it would be fair for Blink to attempt to download ahead especially when seeking.

Assigning to hubbe@ as it sounds like a network issue more than anything.

Also, dropping RBS as, as said above, I don't think it's worth it.

Unable to reproduce the issue on Chrome 64.0.3282.190/CrOS10176.76.0 - Peppy

RE #13
Having a timeout for when we close the connection is going to add large loading delays if there are 100 videos on the page.

It seems to me that the right way to fix this is to not call OnBufferingHaveEnough until the pipeline and demuxer buffers are full.

The 100s of video case is rare, so it's fine to make the < 6 video case better for a slight sacrifice there.

Might be easier to just adjust it so that preload=metadata means "preload a small amount" instead of adding a timeout.

That's effectively what it already means; but if small amount is like 20mb, that's not small :) How small are you thinking?

I'm thinking less than 100k

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/95dc1352e1c3391872d1a26a3852b77007c40f20

commit 95dc1352e1c3391872d1a26a3852b77007c40f20
Author: Fredrik Hubinette <hubbe@google.com>
Date: Wed Feb 28 19:04:11 2018

preload=metadata loads a little instead of none

Change the multibuffer code to preload 1/32th of the normal preload
when "preload=metadata" is used. This should work around problems
that occur because WMPI says we have enough data while the demuxer
may still be filling buffers.

For a lot of videos, this means we'll be preloading 64k.

Bug:  814328 
Change-Id: Iae6945d63bf8298975eb51eda22b16189c7658df
Reviewed-on: https://chromium-review.googlesource.com/937997
Commit-Queue: Fredrik Hubinette <hubbe@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#539911}
[modify] https://crrev.com/95dc1352e1c3391872d1a26a3852b77007c40f20/media/blink/multibuffer_data_source.cc
[modify] https://crrev.com/95dc1352e1c3391872d1a26a3852b77007c40f20/media/blink/multibuffer_data_source_unittest.cc
[modify] https://crrev.com/95dc1352e1c3391872d1a26a3852b77007c40f20/third_party/WebKit/LayoutTests/SlowTests