'{remove,add}sourcebuffer' event firing on MediaSource.activeSourceBuffers also needs to occur when the spec requires due to track selected/enabled state change.

servolk@, do you want to take a stab at fixing this?

Sure, I can take a look

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

commit 01d67d202e8af55c43274d346ed3fb56a16bac65
Author: servolk <servolk@chromium.org>
Date: Thu Aug 25 18:11:27 2016

Deliver change notifications to SourceBuffer track lists.

Also update the activeSourceBuffers list on track status changes.

BUG= 639151 

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

[modify] https://crrev.com/01d67d202e8af55c43274d346ed3fb56a16bac65/third_party/WebKit/LayoutTests/http/tests/media/media-source/mediasource-avtracks.html
[modify] https://crrev.com/01d67d202e8af55c43274d346ed3fb56a16bac65/third_party/WebKit/LayoutTests/media/avtrack/video-track-selected.html
[modify] https://crrev.com/01d67d202e8af55c43274d346ed3fb56a16bac65/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
[modify] https://crrev.com/01d67d202e8af55c43274d346ed3fb56a16bac65/third_party/WebKit/Source/core/html/HTMLMediaElement.h
[modify] https://crrev.com/01d67d202e8af55c43274d346ed3fb56a16bac65/third_party/WebKit/Source/core/html/HTMLMediaSource.h
[modify] https://crrev.com/01d67d202e8af55c43274d346ed3fb56a16bac65/third_party/WebKit/Source/core/html/track/AudioTrack.cpp
[modify] https://crrev.com/01d67d202e8af55c43274d346ed3fb56a16bac65/third_party/WebKit/Source/core/html/track/TrackListBase.h
[modify] https://crrev.com/01d67d202e8af55c43274d346ed3fb56a16bac65/third_party/WebKit/Source/core/html/track/VideoTrack.cpp
[modify] https://crrev.com/01d67d202e8af55c43274d346ed3fb56a16bac65/third_party/WebKit/Source/core/html/track/VideoTrackList.cpp
[modify] https://crrev.com/01d67d202e8af55c43274d346ed3fb56a16bac65/third_party/WebKit/Source/modules/mediasource/MediaSource.cpp
[modify] https://crrev.com/01d67d202e8af55c43274d346ed3fb56a16bac65/third_party/WebKit/Source/modules/mediasource/MediaSource.h
[modify] https://crrev.com/01d67d202e8af55c43274d346ed3fb56a16bac65/third_party/WebKit/Source/modules/mediasource/SourceBuffer.cpp
[modify] https://crrev.com/01d67d202e8af55c43274d346ed3fb56a16bac65/third_party/WebKit/Source/modules/mediasource/SourceBuffer.h

This doesn't appear to fully pass the web-platform-tests/media-source/mediasource-activeSourceBuffers.html test upstream at w3c:
The assertion at https://github.com/w3c/web-platform-tests/blob/master/media-source/mediasource-activesourcebuffers.html#L162 fails (length is still 2, not 1). Note that "removesourcebuffer" on mediaSource.activeSourceBuffers *was* received, otherwise this assertion code path would not have been reached.

I'll investigate and see if I can figure this out quickly.

Strange - I'm getting flaky results on a local Release build for that test. I'm not sure why SourceBufferList.length() might be flaky.

Ah, we have a race.
Though the initialization segment received algorithm now has steps that enable the first audio and first video track (and put their associated SourceBuffer(s) into activeSourceBuffers), the legacy HTMLMediaElement later receives notification to transition to HAVE_METADATA for the first time and enables the first audio/video track if not already enabled. This means that any intervening disable races against that HAVE_METADATA transition.

This is an artifact of our plumbing of readyState changes asynchronously through pipeline's media thread, then back to the renderer thread, so JS is allowed in Chrome to do this race :(

Both the MSE spec and HTML5.1 specs leave room for a little delay here, but with MSE attached, ISTM the "If the media resource is found to have an audio [or video] track" media data processing steps in HTML5.1 need to occur simultaneously with the initialization segment received algorithm, not at some time later during transition to HAVE_METADATA. This would prevent this race artifact and test flakiness IIUC.

I've filed issue 641121 to get the incorrect track auto-re-enablement race fixed. This bug is otherwise fixed.