UPD: Please disregard the exception part ("Uncaught (in promise) DOMException: Failed to execute 'appendBuffer' on 'SourceBuffer': This SourceBuffer is still processing an 'appendBuffer', 'appendStream', or 'remove' operation".), turns out it's a bug in my repro. (Which I corrected, so it shouldn't happen anymore).

The freeze occurs at about 11.2 and the whole video lasts 19 seconds.
I was comparing against Firefox which doesn't plays all 19 seconds without freezing.

Haven't looked yet, but check chrome://media-internals to ensure you're not getting any errors emitted.

Repro (slight freeze when the removal occurs) on Linux 53.0.2785.116 (Official Build) (64-bit).

I suspect that the freeze is due to the remove removing the current GOP being fed to the decoder (removals around the play-head are prone to causing issues like this). I'll try a local repro with debug logging enabled to get more detail.

Also, chrome://media-internals shows lots of DTS>PTS warnings. Is the media muxed correctly (DTS>PTS indicates the stream itself might have problems).

See also https://bugs.chromium.org/p/chromium/issues/detail?id=373039#c6 (this bug might be made more visible due to current conflation of PTS/DTS in Chrome MSE for H264 out-of-order streams. And with the strange DTS > PTS, the removal range actually removed will further differ from a compliant MSE implementation which doesn't conflate PTS/DTS for Remove (or buffered range reporting).

From repro with extra logging:
1. Buffered range [0,12] (DTS == PTS for start and end here, in the stream appended)
2. Buffers from DTS 0..11.2917s read by decode/render pipeline, then
3. App issued remove(11.0067, 734). Note: This removes the current play-head position. Subsequent continuation upon rebuffering will begin at next keyframe continuous in the buffered range containing 11.2917s, unless the app seeks elsewhere.
4. Buffers from [8, 12] re-appended by the app.
5. Buffers from [12, onwards] appended by app.
6. Once the first chunk of #5 ([12,~14.3]) is parsed, including the keyframe at time 12, the pending pipeline read is satisfied with that first keyframe.

** Perhaps Chrome could instead preroll from last keyframe upon rebuffering of media around 11.2917s in this scenario, but removals of the current play-head will cause issues like this currently. Note, the app could explicitly seek to the removal-range start after doing the remove, to deterministically trigger such preroll. Note also that seeks are done in PTS, while removals are done in DTS (in Chrome, due to  bug 373039 ), so there will still be a little jank even in this seek case.

ismena@, can you try a seek(currentTime) immediately after that remove(currentTime,duration) in your repro and see if it helps?

Is this scenario common (removing media at or slightly beyond currentTime, then rebuffering that portion of the timeline without a seek)? Varying MSE implementations (cast, Edge, etc) may have varying behavior when messing with the GOP currently being fed to the decoder.

wolenetz@, thank you for the update.

Seeking after a remove does help to "unfreeze" the feed.

This scenario occurs for us (us being Shaka-player) when switching video tracks (changing to a track with a different resolution). Currently buffered content then needs to be removed and content in new resolution buffered in its' stead.

There are cases in which we clear the buffer completely.  When adapting bitrate, we do not clear the buffer, but when the user manually selects a new track, they expect it to change right away.  (See YouTube's behavior on this, for example.)  If we did not clear the buffer completely, the soonest we could see the new content would be at a segment boundary, which may be up to 10s.  This is not acceptable latency for this operation.

Therefore, when the user manually changes tracks, we clear the buffer completely, accept a brief interruption in playback, and append a new segment under the playhead.  Once that segment is appended, we would expect the playhead to start moving again and for video frames to render.  While the playhead moves, frames do not render until the next keyframe.  So this experience is actually worse than the one we were trying to avoid by clearing everything.

Seeking as a workaround is feasible, but we prefer not to have browser-specific workarounds if we can avoid them.

Keeping this bug open to track potentially prerolling decoder from earlier keyframe in the case of an overlapped append (or a rebuffered GOP for a previously removed GOP containing currentTime), rather than continuing to decode/play from overlapped GOP (or freeze if it was removed) until next overlapping keyframe (which could be in the far future).