We've discussed before. Needs spec work though.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

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

Upping the priority and adjusting the scope just a little. I'm beginning work on a proposal for incubating such a feature in MSE v2 and will post links here when appropriate. Once spec approach is more settled, this bug can track implementation in Chrome.

+EME folks, since likely there will need to be some implementation choices made on how to handle mixed encryption/unencryption bytestream changes (L1<->L3<->unencrypted). e.g. What use cases (if any) require things like splicing unencrypted content into encrypted L1 content?

Server side ad insertion is likely to be a key use case for splicing encrypted (content) with unencrypted (ads).

xhwang:

> Server side ad insertion is likely to be a key use case for splicing encrypted (content) with unencrypted (ads).

My memory is this is now supported (work you did in decoder stream) for same-codec content. IIRC, this works by swapping the decoder at the enc/un-encrypted boundary. In your testing, how does the swap perform? Any hiccups? 

If I'm right that its a full decoder swap, changing codecs shouldn't make a difference performance wise.

Yes, full decoder switch is already supported and once the demuxer starts to support config changes with different codecs, things "should" just work. Note that we'll always try to re-initialize the currently selected decoder first on config change, to avoid the potential overhead of creating a new decoder. But I assume creating a new decoder shouldn't be expensive and don't expect any performance issue, but we have to test it to make sure.

Taking a step back and thinking about it more: basically at the decoder level, in most cases, it's equivalent to two playback (init->decode->stop) sessions glued together, and there's no reason it won't work.

However, things gets a little bit tricky for encrypted playback. Across config/codec change, we are still using the same CDM instance for providing the decryption key, or even perform the decryption/decoding directly. So there's always a potential risk that such switch may not be supported. I am not saying this will not work for the current CDMs we have. Actually it should just work as well. But with such a possibility, we probably should provide some way to query whether such switch will be supported. We can always report failure during append time, but since append can happen before any playback/decoding happens, or any MediaKeys attached, I am not sure how MSE can do so.

@#10, in worst case, "decode err" at runtime unsupported transition (after appending the media causing the transition, and during the demux->decode across the transition) would be the minimum bar for exposure of the problem. UA-specific MediaError.message could elaborate on the reason. Perhaps MCAPI or EME API could be updated to allow queries about supported *EME* transitions of mimetype+codec+EME/DRM constraints.

The initial proposal (I'll share an explainer soon) for the codec switching MSE API would be more like "addSourceBuffer(...)" which returns synchronous error if unsupported (but such contains no indication of EME/DRM constraints of the mimetype+codec).

Initial proposal is available now at:
https://github.com/wolenetz/media-source/blob/codec-switching/codec-switching-explainer.md

> Across config/codec change, we are still using the same CDM instance for providing the decryption key, or even perform the decryption/decoding directly.

I'd like to better understand your point about the decryption key. In a case where:
- EME is active during playabck
- new encrypted content is appended with a different codec

My thinking is we could be in 1 of 2 states

1. the new content uses the same keys as the previous content (in spite of codec switch)

2. the new content uses different keys


Any other state we might be in?


For #1, is that at all likely? I imagine the codec switch actually represents a different file from the server, and I wonder if different files tend to use different keys? 

Related question: how does it work today when using EME and adapting resolution? This is also essentially different files... do they have different keys, triggering new createSession() -> License request flow?


Finally, say you have some magic API that can tell you with certainty whether an encrypted codec transition will go well. What would you need the inputs to that API to be (beyond codec type) to give you that certainty?

This discussion really has very little to do with whether the new codec-encoded stream is using the same or different keys, because as Chris pointed out, different key scenario could already happen in many cases, e.g. with resolution change.

There are multiple potential solutions to support changing decryption key:
- In the license, provide keys for all possible resolutions during the playback.
- Trigger a new license exchange ('encrypted' event) when a new initialization segment is appended.

The problem is that the CDM is typically deeply integrated with the hardware including the hardware decoder. I suspect there are cases where after the CDM/decoder is initialized, it's hard or impossible to switch the operation mode. Again this is speculation. But I knew that for ChromeCast, after the initialization stage, you cannot switch encryption scheme, which is a similar problem. (+slan).

For the magic API, it would be something like CanSwitchCodec(key_system, robustness, is_video). The problem is that at the time of MSE appending, there's no EME involved and you won't know what key_system or robustness would be used.

Now I think about it more, the magic API can probably live in the MediaCapability or EME land. If a player didn't call this API, or ignores the result, then we could hit a decode error later in the playback, which is fine.

@#16, yes, that agrees with my assumption in #11 (...during the demux->decode across the [unsupported by EME/CDM] transition...would be the minimum bar for exposure of the problem...)

With regards to implementation, would MSE require anything special in regards to EME constraints to meet this minimum bar?

@xhwang - friendly ping (see #17).

Working with Mozilla, I've put forth an incubation spec for this feature now at https://github.com/WICG/media-source/tree/codec-switching (it's easier to see the actual spec delta using the htmldiff links in https://github.com/WICG/media-source/blob/codec-switching/README.md)

Plan is to implement this new changeType() API (and updated initialization segment received algorithm) behind a RuntimeEnabledFeature (Experimental) in Blink (to be enabled also by--enable-experimental-web-platform-features) in M69.

I'll put forth a chromestatus entry and a Blink Intent to Implement shortly.

I think we are on the same page :) To be clear just in case:

1. changeType() is only scoped to MSE demuxer.
2. decoder or EME support of codec switch should be in the scope of MC API, e.g. transition() being proposed by 
https://github.com/WICG/media-capabilities/blob/master/explainer.md#transitioning-between-stream-configurations

Note that if changeType() fails, it would be too late a signal. The current MC API transition() proposal is also covering MSE support of codec switch.

@#20, yes, we are on the same page. Thanks.

Note that changeType() might succeed, but later, decode error may occur if the newly appended bytestream is actually not supported or not compliant with MSE. Proper use of MC API (and using well-formed bytestreams) will help apps avoid transition, parsing and real decode errors.

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

commit 06e4121112d87486828cd5811a7700902fb984ec
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Fri Jun 15 01:44:55 2018

MSE: Modernize base::Bind usage for StreamParser callbacks

Since upcoming changeType() work will refactor some of the current code
that creates and passes callbacks to StreamParser::Init(), this CL
modernizes related base::Bind and base::Callback usage to either
base::Bind{Once,Repeating} and base::{Once,Repeating}Callback.

Note that the encrypted media init data callback is the same underlying
type in StreamParser as in Demuxer, so this CL also modernizes the
binding for the Demuxer version of that type.

base::Bind count in //media: before=1425, after=1384

BUG=714018,751838, 605134 

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: Ie8c3ef44a836c5bfa3f34ff300da760dd7f552c1
Reviewed-on: https://chromium-review.googlesource.com/1099935
Reviewed-by: Xiaohan Wang <xhwang@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#567507}
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/base/mock_filters.h
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/base/stream_parser.h
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/filters/chunk_demuxer.cc
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/filters/chunk_demuxer_unittest.cc
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/filters/demuxer_perftest.cc
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/filters/ffmpeg_demuxer_unittest.cc
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/filters/source_buffer_state.cc
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/filters/source_buffer_state.h
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/filters/source_buffer_state_unittest.cc
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/formats/common/stream_parser_test_base.cc
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/formats/mp2t/mp2t_stream_parser.cc
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/formats/mp2t/mp2t_stream_parser.h
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/formats/mp2t/mp2t_stream_parser_unittest.cc
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/formats/mp4/mp4_stream_parser.cc
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/formats/mp4/mp4_stream_parser.h
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/formats/mp4/mp4_stream_parser_unittest.cc
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/formats/mpeg/mpeg_audio_stream_parser_base.cc
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/formats/mpeg/mpeg_audio_stream_parser_base.h
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/formats/webm/webm_stream_parser.cc
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/formats/webm/webm_stream_parser.h
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/formats/webm/webm_stream_parser_unittest.cc
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/test/mock_media_source.cc
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/test/pipeline_integration_fuzzertest.cc
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/test/pipeline_integration_test.cc
[modify] https://crrev.com/06e4121112d87486828cd5811a7700902fb984ec/media/test/pipeline_integration_test_base.cc

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

commit 8722b38aa41c4f579c124371fb9a95e06e277f76
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Fri Jun 22 01:24:50 2018

MSE: Chromium implementation support for SourceBuffer.changeType

Adds ability for ChunkDemuxer and SourceBufferState to indicate whether
a changeType request's type can be satisfied (using successful
construction of an associated StreamParser as the condition), and to
effect changeType by resetting the SourceBufferState's StreamParser.

SourceBufferState's state machine is expanded to allow for enforcing
at-most-one invocation of it's |init_cb_|, while continuing to require
that a newly constructed StreamParser first successfully handle an
initialization segment.

Since this CL does not relax the existing codec-strictness of
StreamParserFactory (and, by extension, MediaSource.addSourceBuffer), it
uses the same strictness for CanChangeType.  Any relaxation can be done
in later CLs.

Also, since such codec strictness is still in place, SourceBufferStream
codec changes (more than just existing support for same-codec config
changes) are allowed only when handling the first initialization segment
following a changeType request, and only if the SourceBuffer had
previously handled an initialization segment.

Later CLs will include changeType pipeline integration tests, Blink API
experimental support for changeType, and changeType web-platform-tests.

BUG= 605134 

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I57e6ef175c9e06ca59db03f8c07ebd6070504af4
Reviewed-on: https://chromium-review.googlesource.com/1110483
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#569492}
[modify] https://crrev.com/8722b38aa41c4f579c124371fb9a95e06e277f76/media/filters/chunk_demuxer.cc
[modify] https://crrev.com/8722b38aa41c4f579c124371fb9a95e06e277f76/media/filters/chunk_demuxer.h
[modify] https://crrev.com/8722b38aa41c4f579c124371fb9a95e06e277f76/media/filters/frame_processor_unittest.cc
[modify] https://crrev.com/8722b38aa41c4f579c124371fb9a95e06e277f76/media/filters/source_buffer_state.cc
[modify] https://crrev.com/8722b38aa41c4f579c124371fb9a95e06e277f76/media/filters/source_buffer_state.h
[modify] https://crrev.com/8722b38aa41c4f579c124371fb9a95e06e277f76/media/filters/source_buffer_stream.cc
[modify] https://crrev.com/8722b38aa41c4f579c124371fb9a95e06e277f76/media/filters/source_buffer_stream.h
[modify] https://crrev.com/8722b38aa41c4f579c124371fb9a95e06e277f76/media/filters/source_buffer_stream_unittest.cc

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

commit 04171dee2f56af46449be6eb0388aa69eb132e4f
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Fri Jun 22 21:13:03 2018

MSE: New changeType PipelineIntegrationTests

Adds tests for changeType buffering and playback, for every combination
of up to 7 audio-only types, and for every combination of up to 6
video-only types.

Sequence mode is used for these because a buffered range gap and
playback stall occurs across the boundary of any audio-only combination
containing the test MP2TS AAC media in segments mode.

Other CLs include changeType chromium impl (pre-requisite for this CL);
and blink impl and new web-platform tests.

BUG= 605134 

Change-Id: I34e6afb9ce104497636958ed2892c1bc6134ff73
Reviewed-on: https://chromium-review.googlesource.com/1110521
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#569775}
[modify] https://crrev.com/04171dee2f56af46449be6eb0388aa69eb132e4f/media/test/mock_media_source.cc
[modify] https://crrev.com/04171dee2f56af46449be6eb0388aa69eb132e4f/media/test/mock_media_source.h
[modify] https://crrev.com/04171dee2f56af46449be6eb0388aa69eb132e4f/media/test/pipeline_integration_test.cc

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

commit ef6f62272c8545ebb905b4689e3ed0a85fb9e418
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Fri Jun 22 22:38:17 2018

MSE: Blink API implementation for experimental SourceBuffer.changeType

Adds SourceBuffer.changeType() method behind MediaSourceExperimental
RunTimeEnabledFlag to implement, along with prerequisite Chromium MSE pipeline
change [a], this method being incubated for inclusion in the next
version of the Media Source Extensions (MSE) spec.

A subsequent CL will contain new web-platform-tests for this method.

See also intent-to-implement [b] and chromestatus entry [c]

[a] https://chromium-review.googlesource.com/c/chromium/src/+/1110483
[b] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/atNyZDs-WXY
[c] https://www.chromestatus.com/features/5719220952236032

BUG= 605134 

Change-Id: I7197bc4f30bfe70eb0733e2b06996651f708637f
Reviewed-on: https://chromium-review.googlesource.com/1111265
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#569810}
[modify] https://crrev.com/ef6f62272c8545ebb905b4689e3ed0a85fb9e418/media/blink/websourcebuffer_impl.cc
[modify] https://crrev.com/ef6f62272c8545ebb905b4689e3ed0a85fb9e418/media/blink/websourcebuffer_impl.h
[modify] https://crrev.com/ef6f62272c8545ebb905b4689e3ed0a85fb9e418/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/ef6f62272c8545ebb905b4689e3ed0a85fb9e418/third_party/blink/public/platform/web_media_source.h
[modify] https://crrev.com/ef6f62272c8545ebb905b4689e3ed0a85fb9e418/third_party/blink/public/platform/web_source_buffer.h
[modify] https://crrev.com/ef6f62272c8545ebb905b4689e3ed0a85fb9e418/third_party/blink/renderer/modules/mediasource/source_buffer.cc
[modify] https://crrev.com/ef6f62272c8545ebb905b4689e3ed0a85fb9e418/third_party/blink/renderer/modules/mediasource/source_buffer.h
[modify] https://crrev.com/ef6f62272c8545ebb905b4689e3ed0a85fb9e418/third_party/blink/renderer/modules/mediasource/source_buffer.idl

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

commit 4cbeb8267d96a2c6aafcb0e6569fc1a25f7ef382
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Fri Jun 22 22:42:09 2018

MSE: Add SourceBuffer.changeType() web-platform-tests

Adds external/wpt tests for the SourceBuffer.changeType() method being
incubated in WICG/media-source spec repo's codec-switching branch.

BUG= 605134 

Change-Id: I52879fdff07473fbec6f5b44296dedd42619455c
Reviewed-on: https://chromium-review.googlesource.com/1111275
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#569812}
[modify] https://crrev.com/4cbeb8267d96a2c6aafcb0e6569fc1a25f7ef382/third_party/WebKit/LayoutTests/external/wpt/media-source/interfaces-expected.txt
[modify] https://crrev.com/4cbeb8267d96a2c6aafcb0e6569fc1a25f7ef382/third_party/WebKit/LayoutTests/external/wpt/media-source/interfaces.html
[add] https://crrev.com/4cbeb8267d96a2c6aafcb0e6569fc1a25f7ef382/third_party/WebKit/LayoutTests/external/wpt/media-source/mediasource-changetype-play.html
[add] https://crrev.com/4cbeb8267d96a2c6aafcb0e6569fc1a25f7ef382/third_party/WebKit/LayoutTests/external/wpt/media-source/mediasource-changetype-util.js
[add] https://crrev.com/4cbeb8267d96a2c6aafcb0e6569fc1a25f7ef382/third_party/WebKit/LayoutTests/external/wpt/media-source/mediasource-changetype.html
[add] https://crrev.com/4cbeb8267d96a2c6aafcb0e6569fc1a25f7ef382/third_party/WebKit/LayoutTests/external/wpt/media-source/mp3/sound_5.mp3
[add] https://crrev.com/4cbeb8267d96a2c6aafcb0e6569fc1a25f7ef382/third_party/WebKit/LayoutTests/external/wpt/media-source/webm/test-vp9.webm

As of #25-26, Chrome M69 now has SourceBuffer.changeType(...) available, if this runtime flag is enabled: chrome://flags/#enable-experimental-web-platform-features

CC+=hbengali@

chromestatus entry: https://www.chromestatus.com/features/5719220952236032
intent-to-implement: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/atNyZDs-WXY

That's fantastic.

How can we try this in production? Origin trial for this (and AV1 decoding, if that still needs to be behind a flag)?

Just needs to send an intent-to-experiment and setup the relevant infrastructure pieces. Matt, Chris and Mounir have experience setting these up, so you can reach out to them for questions. +jaik@ for PM'ing such an effort if AV1 will still be behind a flag at that time.

https://www.chromium.org/blink/launching-features

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

commit 5c41616fb2be2375142d67142afb41bb856d4ce1
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Tue Jun 26 22:26:05 2018

MSE: Rename ChunkDemuxer::CanChangeTypeTo and other small clean-up

Renames this method, and renames its |type| parameter to |content_type|.
Similarly renames ChunkDemuxer::AddId, ChangeType, and static helper
methods' |type| parameter to |content_type|.

BUG= 605134 

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I8b94452732a39157b5ddeba9e563f69aee033690
Reviewed-on: https://chromium-review.googlesource.com/1115704
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#570554}
[modify] https://crrev.com/5c41616fb2be2375142d67142afb41bb856d4ce1/media/blink/websourcebuffer_impl.cc
[modify] https://crrev.com/5c41616fb2be2375142d67142afb41bb856d4ce1/media/filters/chunk_demuxer.cc
[modify] https://crrev.com/5c41616fb2be2375142d67142afb41bb856d4ce1/media/filters/chunk_demuxer.h

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

commit 591c272b6fd33afd585f216740d0c0fd39b1ff81
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Wed Jun 27 18:00:39 2018

MSE: Clarify WebMediaSource::AddSourceBuffer() method

For this interface method and implementation, adds comments, renames
|type| parameter to |content_type|, and removes unnecessary .data()
following Utf8(); all per CR comments on the recently added similar
WebSourceBuffer::{Can}ChangeType() methods.

BUG= 605134 

Change-Id: I0cd259a1a1508edff91287eb60b49721d61e9187
Reviewed-on: https://chromium-review.googlesource.com/1115578
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#570836}
[modify] https://crrev.com/591c272b6fd33afd585f216740d0c0fd39b1ff81/media/blink/webmediasource_impl.cc
[modify] https://crrev.com/591c272b6fd33afd585f216740d0c0fd39b1ff81/media/blink/webmediasource_impl.h
[modify] https://crrev.com/591c272b6fd33afd585f216740d0c0fd39b1ff81/third_party/blink/public/platform/web_media_source.h

You're the owner of a Pri-1 M-69 chrome media issue. M-69 is now in beta and will ship to stable in coming weeks. See go/chromeschedule. Please work on resolving your issue ASAP if it needs fixing for the M-69 branch.

Pri-1 means the work is required for the branch. Alternatively, update the milestone to M-70 or remove the milestone and drop the priority to P-3.

This support landed in M69, but is behind flag. Plan is to begin experimentation via origin trials in M70.

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

commit b024d241fd2b9f9f27e82e30e846192942ee13d7
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Mon Aug 06 23:27:20 2018

MSE: Integrate codec switching API with origin trial framework

Adds a UseCounter for tracking usage of SourceBuffer.changeType(),
retains gating that method's visibility to those in
chrome://flags/#enable-experimental-web-platform-features, and lets
origin trial framework also enable visibility of the method using
feature name "MediaSourceChangeType" for increased experimentation.

BUG= 605134 

Change-Id: Iaf6e1ca58b579cd09b7c07573fb817ec1e69ad82
Reviewed-on: https://chromium-review.googlesource.com/1162583
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#581041}
[add] https://crrev.com/b024d241fd2b9f9f27e82e30e846192942ee13d7/third_party/WebKit/LayoutTests/http/tests/origin_trials/webexposed/mediasource-changetype-origin-trial-interfaces.html
[modify] https://crrev.com/b024d241fd2b9f9f27e82e30e846192942ee13d7/third_party/blink/public/platform/web_feature.mojom
[modify] https://crrev.com/b024d241fd2b9f9f27e82e30e846192942ee13d7/third_party/blink/renderer/modules/mediasource/source_buffer.idl
[modify] https://crrev.com/b024d241fd2b9f9f27e82e30e846192942ee13d7/third_party/blink/renderer/platform/runtime_enabled_features.json5
[modify] https://crrev.com/b024d241fd2b9f9f27e82e30e846192942ee13d7/tools/metrics/histograms/enums.xml

Intent-to-Experiment: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/A5Ux5CzpeWs/KjIcVDmpDAAJ

Instead of OT/experimenting, intending to ship (M-70) since FF already ships on-by-default, risk is low, and need is high: 
Intent-to-Ship: https://groups.google.com/a/chromium.org/d/topic/blink-dev/K_OFPxA_whE/discussion

I2S is approved. CL to ship it in M70 is in CR currently @ https://chromium-review.googlesource.com/c/chromium/src/+/1182292

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

commit fff5908bf2e267b94429206162defb84ca0d8dfa
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Tue Aug 21 18:27:39 2018

MSE: Ship SourceBuffer.changeType

With intent-to-ship approved [1], this change undoes the ephemeral
origin trial integration previously landed in r581041 and ships
SourceBuffer.changeType() (so that its use no longer requires an
experimental flag.) This change retains the UseCounter for this
new MSE API method that was added in r581041.

[1] https://groups.google.com/a/chromium.org/d/topic/blink-dev/K_OFPxA_whE/discussion

BUG= 605134 

Change-Id: Ie10f8ef71513998dc8672786bc8fea12bb0ad150
Reviewed-on: https://chromium-review.googlesource.com/1182292
Reviewed-by: Philip Jägenstedt <foolip@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#584848}
[delete] https://crrev.com/b4bba9de032e036a87ad1e163734c002ff8a7ccf/third_party/WebKit/LayoutTests/http/tests/origin_trials/webexposed/mediasource-changetype-origin-trial-interfaces.html
[modify] https://crrev.com/fff5908bf2e267b94429206162defb84ca0d8dfa/third_party/WebKit/LayoutTests/virtual/stable/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/fff5908bf2e267b94429206162defb84ca0d8dfa/third_party/blink/renderer/modules/mediasource/source_buffer.idl
[modify] https://crrev.com/fff5908bf2e267b94429206162defb84ca0d8dfa/third_party/blink/renderer/platform/runtime_enabled_features.json5

#41 ships this feature (M70, should be in next Dev/Canary).

The first releases containing #41 can be found (once release) via https://storage.googleapis.com/chromium-find-releases-static/fff.html#fff5908bf2e267b94429206162defb84ca0d8dfa

FYI, https://chromiumdash.appspot.com/commit/fff5908bf2e267b94429206162defb84ca0d8dfa also works to know which release has this feature.