Seems like vimeo is failing to buffer data, which causes playing to stop. Here are the errors I see in the javascript console when buffering fails:

Uncaught TypeError: Cannot read property 'currentTime' of undefined
Uncaught TypeError: Cannot read property 'message' of null

Maybe a bug in their player?

This seems to be an error in their player and far outside of my expertise.
Assigning back to johnpallet, maybe he can reach out to Vimeo.

Matt, per discussions at FOMS is there a plan for MSE to change how it handles a lack of data in the buffer?

Discussion at FOMS was to add ability for app to request MSE instance to
"play through unbuffered regions". I imagine we would not want this
behavior all the time though; only if app requests it.

Repro on linux (persistent pause at time 1:11 in the video)
Chrome 54.0.2840.59 (Official Build) (64-bit)
tail of chrome://media-internals shows indeed that the player is put into suspended state, due to having been paused for 15 seconds. Even after that, clicking play doesn't resume the video. Seems like a buffering issue. Devtools console confirms that the HTMLMediaElement.buffered has just one range: [0,71.999999)

event	PLAY
00:00:10 688	height	2160
00:00:10 688	width	3840
00:01:41 87	event	PAUSE
00:01:56 102	pipeline_state	kSuspending


Inspecting the error in the js console:
Uncaught TypeError: Cannot read property 'currentTime' of undefined(…)
--> This appears to be trying to handle a QuotaExceededError, but the js's "this._video" is undefined in that context for some reason. It looks like a player issue to me, not a Chrome issue. The fact that it doesn't repro on Edge is likely due to differing MSE coded frame removal range and GC heuristic across browser implementations.

johnpallett@ : can you contact Vimeo and see if this is a known issue in their player please?

Also, w.r.t. #5 and #6, this is not an issue with MSE not allowing a mode to "play through unbuffered regions". It's that the buffering by the app is completely stopped due to app error in exception handling of an attempted appendBuffer which gave "QuotaExceededError". This exception should be handled gracefully by apps; it's a mechanism the spec allows for the user agent to signal the app that there's too much currently buffered to accept the attempted appendBuffer, and the app should do one or more of:
1) wait for playback to proceed a bit further and retry (since GC heuristic might depend on currentTime), or
2) retry the append with a smaller piece of the buffer, or
3) do an explicit SourceBuffer.remove(start,end) to evict buffered frames to make room for a retry of the appendBuffer.

In degenerate cases, if the keyframe interval is so large that GOPs are huge, then this QuotaExceededError will occur and may not have a workaround since making room for appending the remainder of the current (huge) GOP would involve explicit removal of the current GOP's keyframe (and all of its currently buffered dependencies), and nothing further would be buffered until the next keyframe is parsed out of a successful appendBuffer.

This is just a silly bug on our (Vimeo's) end. Working on a fix now

Just to provide a little more info. We have code that removes old parts of the buffer when there is a `QuotaExceededError` which is usually only triggered for 2K/4K playback. The code to remove the old parts of the buffer had been erroring. AFAIK Chrome is a little more aggressive than EDGE when it comes to the maximum quota size which would explain why it worked okay in EDGE.

The fix should go out next Monday.

@#10, that's great news that the player issue is understood and a fix is in flight. In addition to possibly higher quotas, I believe Edge may have a more aggressive buffering eviction algorithm. We previously had to make our eviction algorithm less aggressive in Chrome to enable different usage scenarios (seek, then buffer at seek target vs buffer at seek target, then seek) to reduce automatic evictions of media that was likely meant to be played soon and instead give the app more control over what it might want to evict.

+servolk@ for context on this, since non-android Chromecast has lower limits than Chrome.

Thanks @wolenetz for the explanation. Fix has been deployed on our end.

@#12 Confirmed, playback works here.

Tested both Windows and Linux, both platforms work now.  Closing.

On Linux, Chrome 54.0.2840.90 (Official Build) (64-bit), when I try to repro, I get janky playback with periodic playback halts for a second or two and then resumption. Around 1-2 minutes into the media timeline, playback remains halted. webkitDroppedFrameCount is about 1/3 of webkitDecodedFrameCount, indicating decoder isn't keeping up on this machine, but I also found a couple weird symptoms demonstrating that the player still seems to have some buffering bug. Steps:
1. Load the repro page from original post. Open devtools console. Set the video to HD 4K. *don't click play yet*
2. Enter the following into devtools console to get periodic stats from the video element.
function showBufs(b) { for (var i=0; i < b.length; b++) { console.log("\tbuffered[" + i + "]: " + b.start(i) + "-" + b.end(i) + "\n"); } }; var v=$('video')[0]; setInterval(function() { console.log("currentTime = " + v.currentTime + ", dropped = " + v.webkitDroppedFrameCount + ", decoded = " + v.webkitDecodedFrameCount + "\n"); showBufs(v.buffered); }, 1000);

3. Observe (without clicking play), that buffered amounts increase to > 1 minute, then the first few seconds of media is removed. Clicking play at this point gets immediate stall.

For example, steps 2 and 3 show the following for me:

currentTime = 0, dropped = 0, decoded = 4

VM2227:1 	buffered[0]: 0-47.999999

VM2227:1 currentTime = 0, dropped = 0, decoded = 4

VM2227:1 	buffered[0]: 0-60

VM2227:1 currentTime = 0, dropped = 0, decoded = 4

VM2227:1 	buffered[0]: 0-66

VM2227:1 currentTime = 0, dropped = 0, decoded = 4

VM2227:1 	buffered[0]: 0-71.999999

VM2227:1 currentTime = 0, dropped = 0, decoded = 4

VM2227:1 	buffered[0]: 3-71.999999

VM2227:1 currentTime = 0, dropped = 0, decoded = 4

VM2227:1 	buffered[0]: 3-71.999999

VM2227:1 currentTime = 0, dropped = 0, decoded = 4

VM2227:1 	buffered[0]: 3-71.999999

VM2227:1 currentTime = 0, dropped = 0, decoded = 4

VM2227:1 	buffered[0]: 3-71.999999

VM2227:1 currentTime = 0, dropped = 0, decoded = 4

VM2227:1 	buffered[0]: 3-71.999999

Thanks. We preload the video before you click play on vimeo.com so I suspect what is happening is when you pick 4K it starts downloading and appending 4K segments then as soon as it hits the first QuotaExceededError it tries to remove part of the buffer which in this case there is nothing to remove. I don't have the code in front of me but I think it's probably calling sourceBuffer.remove(0, 0) since the currentTime of the video is 0. 

What's interesting is the buffered range starting at 3. We have keyframes every 3 seconds. Is it possible that calling remove from 0 to 0 may actually remove from 0 to the next keyframe?

I can confirm tomorrow if that is actually what is happening. Will need to make a few tweaks to fix this. 

I don't see this bug repro on chrome 56.0.2902.0. the video does stutter a lot in fullscreen and windowed state, but never freeze.

@#18, if indeed sourceBuffer.remove(0, 0) is attempted, since start >= end time, there should be a TypeError exception. However, if something like sourceBuffer.remove(0,0.000001) is attempted, and the keyframe timestamp is 0, then the keyframe and all of the frames which depend on it will be removed.

Explicit remove() operations that remove coded frames near currentTime (even if a little before currentTime) remove the whole GOP, which could include what is currently being fed to the decoder. Even if overlapping re-appends occur at this point, the decode will only continue at the *next* continuous (with new buffered or the previously removed GOP) GOP keyframe *beyond* the frame last fed to the decoder. IOW, we currently dont preroll from an earlier keyframe without an explicit seek. tl;dr: don't remove() a GOP that overlaps currentTime unless you really don't mean to have anything buffered at that time.

Also, since we currently unfortunately conflate PTS and DTS in reporting buffered ranges and doing the remove() operation, removing GOPs that are near the currentTime are similarly risky.

Given these two risks of jankiness/stalls: it'd probably be safest to preserve the GOP prior to the GOP containing currentTime when explicitly remove()'ing media. Note that with 3 second GOP durations, and the repro buffering ahead about 66 seconds before encountering appendBuffer QuotaExceededErrors (inferred from the behavior in #15), being even slightly less aggressive about explicitly evicting GOPs near currentTime should give you lots of buffering capacity beyond currentTime for 4K on desktop.

Inconsistent results for me, but I was able to reproduce.  The following steps increases the odds of repro:

- Following the steps above (Set to 4K, add the function)
- WAIT until the buffering message reads 3-71.999999 before hitting play

... still doesn't happen 100% of the time but it does happen more often.

Thanks. I just checked and it looks like we are indeed calling `remove(0, 0.1)`. It's an oversight. During regular playback, it will remove from 0 to currentTime - 6 when it encounters QuotaExceededError. The issue here is that it is trying to buffer ahead too far when locked into a quality before attempting playback. 

Our logic about how far to buffer ahead is not very smart right now. The quickest fix on our end is to decrease how far we should buffer ahead for 2K and 4K streams or at least decrease it while the video is not playing to avoid issues like this.

The problem specifically has to do with running into the QuotaExceededError while our player still thinks it should buffer further ahead. I would imagine this results in some kind of infinite loop.

I will look more closely at it tomorrow. Thanks again for the insight.

I also note suspicious log entries in chrome://media-internals when playback isn't indefinitely stalled but is periodically janky and dropping frames around the same time that the buffered ranges start time is moving forwards (indicating implicit or explicit coded frame eviction might be triggering jankiness) and within ~3 seconds of currentTime (indicating perhaps too much is being explicitly evicted by the app too close to currentTime). Log entries are like:
"Skipping splice frame generation: first new buffer at 149994666us begins at or before existing buffer at 149994666us."
This log message and associated audio splicer crossfade was just removed from M56 (Canary/Dev builds) by chcunningham@. Prior to that removal, this log indicated that an *audio* coded frame with same timestamp as an already-buffered audio coded frame was processed in appendBuffer(). This suggests that similar might be happening for video coded frames (for which there's no similar log in our code currently). If that is the case, then an overlapped append of already buffered media could be causing similar jank as an explicit remove + re-append (described in #20) due to the implicit removal of the overlapped buffers as part of processing the newly appended buffers. 

tl;dr: To reduce risk of jankiness further, also don't overlap-append a GOP that is near currentTime, as such will involve an automatic eviction of the overlapped piece of the previously buffered GOP and may introduce jankiness if the eviction is near currentTime.

I noticed when start playback first, then change resolution to 4k, it is 100% repro. If change resolution first to 4k, then play video, this bug NOT repro.

We pushed out a fix couple of days ago. Can some one confirm and close this issue?

Confirmed:
- Used the showBufs() command and did not see any errors, playback worked
- Changed resolution after starting playback; worked fine

Marking as verified.

naren@, vimeo 4k video is not playable in ChromeOS LINK (high end chromebook), is it a known issue to you? When I switch to 4k resolution, video freeze, then a warning message is shown "Having issues? swtich to Auto for smoother streaming"
This issue is not observed on Mac or Win device.

even 2k resolution is not supported.

+wolenetz any suggestions on how to diagnose for +iamcraigcampbell@gmail.com?

@#27-28: Some questions:

1) Is the media encrypted? If so, lack of playback of 4k or 2k on specific platforms could be related.
2) What does chrome://media-internals show? Maybe there's some decoder, or platform-specific issue.
3) What do the video element's buffered and currentTime attributes report before and during a repro? Perhaps a) there's a stall at a gap between buffered ranges in the timeline, or b) there's a stall at the end of the buffered time and the app is unsuccessfully fetching+appending the next buffers (like earlier in this bug).

In #15's code snippet, s/b++/i++/, otherwise at most only the first buffered range will be reported.

 Issue 697527  has been merged into this issue.

4k video plays normally on chromebook LINK + 58.0.3021.3. do we still want to keep this bug?

LINK was the last and only reason it was still open; since you've verified LINK I'm going to mark the entire bug verified.

activate this bug. This issue repro again on LINK device. The video playback pause every a few seconds in playing 4k video.

sorry false alarm. After switch to a more stable network connection, this issue not repro anymore.