Hmm, this is a bit odd. You're specifying preload=none so nothing gets loaded by default, but clicking the play button actually just seems to run load() but not a subsequent play(). +controls, blink folk.

I can't reproduce this. What I see is:

1. Open page
2. Press play
3. The video preloads but doesn't play
4. Press play again
5. The video plays

Given the source code of the page, that sounds to be WAI. Can you elaborate what's happening? Maybe with a screenshot?

dalecurtis@, if you were able to reproduce, do you have more information about the behaviour you saw? on which platform?

Sorry my point wasn't clear. Is step 2 -> 3 really WAI? I.e. Why does pressing play invoke load but not play once load completes?

The page has:
```
<script>
var vid = document.getElementById("myVideo");
var set = false;
vid.addEventListener('play',function(){
  if(set == false){
  vid.pause();
  }
  set = true;
});
</script>
```

Which makes me think the video will fail to play the first time.

However, my understanding of the bug report is that the controls are frozen and it's no longer possible to interact with the video which I can reproduce.

Ah, I missed that snippet of JS during my inspection. Yeah can't repro then.

The javascript snippet is to simulate on demand preroll ads. 
Such that on the play event, the player will pause and play a preroll ad. Once the ad finishes, the video will play.
Setting aside the fact that you have to click play twice to get a video to work, you should still be able to reproduce an issue (intermittently) when the video just freezes at 0.0 and no amount of interaction with the page helps. 
The only way is to refresh the page. 
This issue is never seen with Hls videos. or m3u8. 
It happens only with mp4 videos on chrome. 

Thanks for looking into this! 

Any updates on this  yet? 

Here's a screencast of the issue, for reference.

Deleted: videofreeze_error.mp4 823 KB

	videofreeze_error.mp4 823 KB View Download

Hmm, can you go to chrome://media-internals and see if any audio streams are present? 

No Audio streams present. Here's a screenshot.

Deleted: Screen Shot 2016-09-16 at 1.44.40 PM.jpg 29.3 KB

	Screen Shot 2016-09-16 at 1.44.40 PM.jpg 29.3 KB View Download

Does the system you're playing on have audio hardware?

I'm on a macbook pro, so the audio hardware would be the standard speakers on the laptop? Or is it something else you are looking for?

Also, please ignore the earlier screenshot. 
I cleared all browser cookies and restarted the browser.
And replicated the issue.
This is what I see in the Audio streams now:

Deleted: Screen Shot 2016-09-16 at 2.02.19 PM.jpg 56.3 KB

	Screen Shot 2016-09-16 at 2.02.19 PM.jpg 56.3 KB View Download

Okay that's better, but stream is still stopped for some reason, which is likely why video is not advancing. Just to check, you can hear audio on this device from other websites?

Yes I can hear the audio when a video plays as expected and does not fail like this.

When the playback fails, can you grab the contents of

chrome://histograms/Media.AudioOutputControllerPlaybackStartupSuccess

Here's the contents: 

Deleted: Screen Shot 2016-09-16 at 2.22.06 PM.jpg 57.3 KB

	Screen Shot 2016-09-16 at 2.22.06 PM.jpg 57.3 KB View Download

Has anyone on the chromium team been able to reproduce this issue on the url above?
Is the screencast giving a better idea of what is the issue at hand here?

No sorry, we haven't been able to reproduce the issue. Usually this type of issue is a result of the audio hardware not working, but your stats look okay in the above histogram so I'm not sure what might be going on.

When the video is frozen for you can you grab the contents of chrome://media-internals for that player?

Thanks a lot for quick response. I am attaching few screenshots and logs that we capture when we see the issue. 

Note: I work at the same company as Priyanka (person who reported the issue), having said that we did received multiple reports outside our network who were able to reproduce the issue. 

Any feedback regarding this issue is greatly appreciated. 
thanks
Shyam 

Deleted: Screen Shot 2016-09-16 at 5.33.49 PM.jpg 123 KB

	Screen Shot 2016-09-16 at 5.33.49 PM.jpg 123 KB View Download

Deleted: Screen Shot 2016-09-16 at 5.34.05 PM.jpg 168 KB

	Screen Shot 2016-09-16 at 5.34.05 PM.jpg 168 KB View Download

Deleted: Screen Shot 2016-09-16 at 5.34.33 PM.jpg 364 KB

	Screen Shot 2016-09-16 at 5.34.33 PM.jpg 364 KB View Download

Deleted: ChromeMediaInternalsLog.txt 2.7 KB

ChromeMediaInternalsLog.txt 2.7 KB View Download

sedamkar@: Can you please test with Chrome Canary (from today or later) to see if the issue was resolved by reorder queue changes that went in on Friday? Thanks!

We are able to reproduce the issue even on the Chrome Canary Version 55.0.2866.0 canary. We are able to reproduce the issue on the test page (http://cs1.brightcodes.net/pdias/samples/gannett-ads-preload.html) as well as on our production video page http://www.usatoday.com/story/news/nation-now/2016/09/19/experts-homemade-bombs-weaker-but-easier-make/90716356/

But there seems to be some unique behavior compared to regular chrome vs Canary. In canary if you use the scrubber the video starts to play(even though its stuck at 0.0) where as in regular chrome any action on the player wont make the video to play. 

Also do you have any data on how many users might be affected with this issue? since we need to give an update to our stakeholders and unfortunately we don't have quantifying number to say how bad this issue is. Any information regarding that would be of great help. 
thanks
shyam 

I was able to reproduce this once, but the issue went away after clearing Chrome settings (Setting > Advanced > Reset settings). Does this action work around the issue for you as well?

cc:hubbe who I think is working on a fix for this.

Might be related to https://bugs.chromium.org/p/chromium/issues/detail?id=648395
Does the problem go away if you don't do preload=none ?

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

commit 3b2a5629da155db59d3449a6d640c107e91aa14d
Author: hubbe <hubbe@chromium.org>
Date: Wed Sep 21 07:17:46 2016

Fix a timing bug in multibuffer.

When "cancel on defer is on", the multibuffer reader can sometimes get
delete before it is allowed to deliver a pending read callback. This basically
hangs the multibuffer data source as it waits for the read callback forever.

BUG= 648395 ,  647867 ,  646434 

Review-Url: https://codereview.chromium.org/2357773003
Cr-Commit-Position: refs/heads/master@{#419995}

[modify] https://crrev.com/3b2a5629da155db59d3449a6d640c107e91aa14d/media/blink/multibuffer_data_source.cc
[modify] https://crrev.com/3b2a5629da155db59d3449a6d640c107e91aa14d/media/blink/multibuffer_data_source.h
[modify] https://crrev.com/3b2a5629da155db59d3449a6d640c107e91aa14d/media/blink/multibuffer_data_source_unittest.cc

It does appear similar to the issue mentioned below: https://bugs.chromium.org/p/chromium/issues/detail?id=648395

Although, they are seeing this on "preload=metadata" and we can reproduce it on "preload=none".  So it doesn't look like its influenced by what preload is set to.

Reseting chrome settings on Canary [Version 55.0.2867.0 canary (64-bit)] and regular Chrome [Version 53.0.2785.116 (64-bit)] did not resolve the issue for me. I can still reproduce on both the versions of Chrome.

Is the bug fix that @bugdroid1  mentioned a part of later Chrome versions?

If it is the same issue, the preload=auto will work around the issue.

The fix for this is in now in he chrome canary build.
psav244@gmail.com, can you check if this works for you with chrome canary?

@chrometeam, could you please confirm if this issue is reproducible only if we use ".mp4"? if we move to HLS (m3u8) this should not be an issue? For our usatoday.com site we moved to m3u8 and we haven't seen the issue. Having said that earlier also not all our users were experiencing this issue so wanted to see if we can get some confirmation  on whether moving to m3u8 will solve this or not. 

@ hubbe@chromium.org, Thanks for the update!! 
We haven't been able to reproduce this issue on Canary for the test url: http://cs1.brightcodes.net/pdias/samples/gannett-ads-preload.html

As Shyam mentioned above, we also have not been able to reproduce this issue on one of our sites - usatoday.com since yesterday, after moving to use m3u8 format for our videos.
Was this bug specific to only .mp4 videos?

Thanks,
Priyanka

@sedashy, m3u8 / HLS files will not play in Chrome Desktop w/o a transmuxing layer like hls.js.

We do use brightcove (which I believe uses hls.js) to play the video. So m3u8 should work on all browsers within brightcove player. 

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

commit b39d634c0efdd5912bfca4336ba9dc908e67fe10
Author: Fredrik Hubinette <hubbe@google.com>
Date: Thu Sep 22 22:36:17 2016

Fix a timing bug in multibuffer.

When "cancel on defer is on", the multibuffer reader can sometimes get
delete before it is allowed to deliver a pending read callback. This basically
hangs the multibuffer data source as it waits for the read callback forever.

BUG= 648395 ,  647867 ,  646434 

Review-Url: https://codereview.chromium.org/2357773003
Cr-Commit-Position: refs/heads/master@{#419995}
(cherry picked from commit 3b2a5629da155db59d3449a6d640c107e91aa14d)

Review URL: https://codereview.chromium.org/2362953002 .

Cr-Commit-Position: refs/branch-heads/2840@{#500}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/b39d634c0efdd5912bfca4336ba9dc908e67fe10/media/blink/multibuffer_data_source.cc
[modify] https://crrev.com/b39d634c0efdd5912bfca4336ba9dc908e67fe10/media/blink/multibuffer_data_source.h
[modify] https://crrev.com/b39d634c0efdd5912bfca4336ba9dc908e67fe10/media/blink/multibuffer_data_source_unittest.cc

Verified the issue on Mac 10.11.6 using chrome beta version #54.0.2840.41 as per the comment #0
Observed that the fix is working as expected.

Attaching screencast for reference

Hence, adding the verified labels.

Deleted: 646434.mp4 2.0 MB

	646434.mp4 2.0 MB View Download

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

commit b39d634c0efdd5912bfca4336ba9dc908e67fe10
Author: Fredrik Hubinette <hubbe@google.com>
Date: Thu Sep 22 22:36:17 2016

Fix a timing bug in multibuffer.

When "cancel on defer is on", the multibuffer reader can sometimes get
delete before it is allowed to deliver a pending read callback. This basically
hangs the multibuffer data source as it waits for the read callback forever.

BUG= 648395 ,  647867 ,  646434 

Review-Url: https://codereview.chromium.org/2357773003
Cr-Commit-Position: refs/heads/master@{#419995}
(cherry picked from commit 3b2a5629da155db59d3449a6d640c107e91aa14d)

Review URL: https://codereview.chromium.org/2362953002 .

Cr-Commit-Position: refs/branch-heads/2840@{#500}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/b39d634c0efdd5912bfca4336ba9dc908e67fe10/media/blink/multibuffer_data_source.cc
[modify] https://crrev.com/b39d634c0efdd5912bfca4336ba9dc908e67fe10/media/blink/multibuffer_data_source.h
[modify] https://crrev.com/b39d634c0efdd5912bfca4336ba9dc908e67fe10/media/blink/multibuffer_data_source_unittest.cc