media: Enable Unified Media Pipeline for MSE and EME on Android

media: Enable Unified Media Pipeline for MSE and EME on Android

Enables Mojo Media on Android to support EME in the unified media
pipeline. This introduces MojoCdm, MojoAudioDecoder and encrytped
stream support in AndroidVideoDecodeAccelerator.

This CL also enables MSE in the unified media pipeline. The fallback
logic for MSE (IsUnifiedMediaPipelineEnabledForMse()) is removed.

Also partially reverts f92f4e5c849c028db73fbe06912685a77b978ee4 which
added "LoadType" in createMediaPlayer() to implement the fallback
logic for MSE.

BUG=455905, 521731
TEST=Encrypted audio/video plays in default Chrome for Android build
with and without unified media pipeline.

Committed: https://crrev.com/92d0fffc36695c099005bf05862145a89d918f28
Cr-Commit-Position: refs/heads/master@{#383331}

[xhwang, 2016-03-23 16:35:53]

xhwang@chromium.org changed reviewers:
+ dalecurtis@chromium.org, ddorwin@chromium.org

[xhwang, 2016-03-23 16:35:55]

This will wait until timav@ land his CL and we finish a thorough test. But I
think the change of this CL is independent of timav@'s work. So I'd like to send
it out earlier for discussion.

dalecurtis / ddorwin: PTAL
timav / sandersd / wolenetz: FYI

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
File content/renderer/render_frame_impl.cc (right):

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
content/renderer/render_frame_impl.cc:774: }
ddorwin: So for HLS and .mp4 URL we'll still use mojo CDM if unified pipeline is
enabled. I think this is fine because EME isn't supported in either case
anyways.

https://chromiumcodereview.appspot.com/1825763002/diff/1/media/filters/stream...
File media/filters/stream_parser_factory.cc (right):

https://chromiumcodereview.appspot.com/1825763002/diff/1/media/filters/stream...
media/filters/stream_parser_factory.cc:357:
!media::IsUnifiedMediaPipelineEnabled()) {
dalecurtis: How does the current code work given the fact that
media::IsUnifiedMediaPipelineEnabledForMse() doesn't check the
field-trial/experiment?

[DaleCurtis, 2016-03-23 17:51:54]

\o/ -- lgtm

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
File content/renderer/render_frame_impl.cc (right):

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
content/renderer/render_frame_impl.cc:763: bool UseWebMediaPlayerImpl(const
GURL& url) {
I wonder if we should have a if (!url.isHttpOrHttps()) return true here to avoid
any accidental blob/data urls ending with hls or mp4 extensions.

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
content/renderer/render_frame_impl.cc:774: }
On 2016/03/23 at 16:35:54, xhwang wrote:
> ddorwin: So for HLS and .mp4 URL we'll still use mojo CDM if unified pipeline
is enabled. I think this is fine because EME isn't supported in either case
anyways.

At least for mp4, this is only in the case that we don't have a MediaCodec, so
we couldn't play the mp4 even if EME was supported.

https://chromiumcodereview.appspot.com/1825763002/diff/1/media/filters/stream...
File media/filters/stream_parser_factory.cc (right):

https://chromiumcodereview.appspot.com/1825763002/diff/1/media/filters/stream...
media/filters/stream_parser_factory.cc:357:
!media::IsUnifiedMediaPipelineEnabled()) {
On 2016/03/23 at 16:35:55, xhwang wrote:
> dalecurtis: How does the current code work given the fact that
media::IsUnifiedMediaPipelineEnabledForMse() doesn't check the
field-trial/experiment?

Previously this code only enabled MSE when no MediaCodec was available, i.e.
cases that WMPA never supported -- so it wasn't part of the field trial /
experiment.

[Tima Vaisburd, 2016-03-23 19:27:52]

timav@chromium.org changed reviewers:
+ timav@chromium.org

[Tima Vaisburd, 2016-03-23 19:27:53]

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
File content/renderer/render_frame_impl.cc (right):

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
content/renderer/render_frame_impl.cc:5906: if (media::IsMojoCdmEnabled()) {
It looks like if ENABLE_MOJO_CDM is defined, and media::IsMojoCdmEnabled()
returns false, and neither CDMS is defined, this method returns nullptr. Is this
expected?

[xhwang, 2016-03-23 20:44:06]

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
File content/renderer/render_frame_impl.cc (right):

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
content/renderer/render_frame_impl.cc:5906: if (media::IsMojoCdmEnabled()) {
On 2016/03/23 19:27:52, Tima Vaisburd wrote:
> It looks like if ENABLE_MOJO_CDM is defined, and media::IsMojoCdmEnabled()
> returns false, and neither CDMS is defined, this method returns nullptr. Is
this
> expected?

Today we have ENABLE_BROWSER_CDMS enabled by default on Android. So in the case
you described, we'll fallback to linr 5919, which is the old WMPA EME path.

In the future, when to switch to mojo CDM exclusively and drop
ENABLE_BROWSER_CDMS, we'll end up with a null CDM factory, which is expected.

[ddorwin, 2016-03-24 18:05:11]

https://codereview.chromium.org/1825763002/diff/1/content/renderer/render_fra...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/1825763002/diff/1/content/renderer/render_fra...
content/renderer/render_frame_impl.cc:769: // software and hardware decoders are
not available.
s/hardware/platform/

https://codereview.chromium.org/1825763002/diff/1/content/renderer/render_fra...
content/renderer/render_frame_impl.cc:774: }
On 2016/03/23 17:51:54, DaleCurtis wrote:
> On 2016/03/23 at 16:35:54, xhwang wrote:
> > ddorwin: So for HLS and .mp4 URL we'll still use mojo CDM if unified
pipeline
> is enabled. I think this is fine because EME isn't supported in either case
> anyways.
> 
> At least for mp4, this is only in the case that we don't have a MediaCodec, so
> we couldn't play the mp4 even if EME was supported.

For HLS, it doesn't make sense to use EME, so that's fine.

For MP4, .src= does not work anywhere because of
https://bugs.chromium.org/p/chromium/issues/detail?id=170793, so this is fine
for now.

If we fixed that bug:
* Not having platform decoder support means (I believe) that MediaCodec is not
available or the GPU process is not working. The former means EME won't work
anyway. The latter could work with WMPA, but I don't think it is an expected
case. Dale?
* Clear Key doesn't need platform decoders, but we won't use Mojo CDM for that,
right?

MimeUtil appears to be accurate (for H.264). When the unified pipeline is
enabled, we require HasPlatformDecoderSupport() for encrypted content.

More generally, do we plan to continue to support EME in the WMPA path once
we've fully switched to WMPI? Since MediaCodec is necessary, it would seem that
broken GPU process is the only case where we might fall back. (The current
MimeUtil logic doesn't appear to report support in this case anyway.)

https://codereview.chromium.org/1825763002/diff/1/media/base/media.cc
File media/base/media.cc (right):

https://codereview.chromium.org/1825763002/diff/1/media/base/media.cc#newcode77
media/base/media.cc:77: bool IsMojoCdmEnabled() {
Should this be ifdef'd to ENABLE_MOJO_CDMS?

https://codereview.chromium.org/1825763002/diff/1/media/base/media.h
File media/base/media.h (right):

https://codereview.chromium.org/1825763002/diff/1/media/base/media.h#newcode52
media/base/media.h:52: 
Do we need a flag so we can selectively enable the new path for MSE separate
from .src=?

[DaleCurtis, 2016-03-24 18:09:10]

https://codereview.chromium.org/1825763002/diff/1/content/renderer/render_fra...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/1825763002/diff/1/content/renderer/render_fra...
content/renderer/render_frame_impl.cc:774: }
On 2016/03/24 at 18:05:11, ddorwin wrote:
> On 2016/03/23 17:51:54, DaleCurtis wrote:
> > On 2016/03/23 at 16:35:54, xhwang wrote:
> > > ddorwin: So for HLS and .mp4 URL we'll still use mojo CDM if unified
pipeline
> > is enabled. I think this is fine because EME isn't supported in either case
> > anyways.
> > 
> > At least for mp4, this is only in the case that we don't have a MediaCodec,
so
> > we couldn't play the mp4 even if EME was supported.
> 
> For HLS, it doesn't make sense to use EME, so that's fine.
> 
> For MP4, .src= does not work anywhere because of
https://bugs.chromium.org/p/chromium/issues/detail?id=170793, so this is fine
for now.
> 
> If we fixed that bug:
> * Not having platform decoder support means (I believe) that MediaCodec is not
available or the GPU process is not working. The former means EME won't work
anyway. The latter could work with WMPA, but I don't think it is an expected
case. Dale?

Even if we "fixed" that bug for desktop/unified path, I don't think it would
ever be fixed for MediaPlayer so that case seems impossible.

> * Clear Key doesn't need platform decoders, but we won't use Mojo CDM for
that, right?
> 
> MimeUtil appears to be accurate (for H.264). When the unified pipeline is
enabled, we require HasPlatformDecoderSupport() for encrypted content.
> 
> More generally, do we plan to continue to support EME in the WMPA path once
we've fully switched to WMPI? Since MediaCodec is necessary, it would seem that
broken GPU process is the only case where we might fall back. (The current
MimeUtil logic doesn't appear to report support in this case anyway.)

I expect we'll kill off the non-unified MSE paths very quickly (M53?) since it's
not needed for any blacklist or non-Chrome codecs.

[xhwang, 2016-03-24 21:26:04]

Thanks! PTAL again!

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
File content/renderer/render_frame_impl.cc (right):

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
content/renderer/render_frame_impl.cc:763: bool UseWebMediaPlayerImpl(const
GURL& url) {
On 2016/03/23 17:51:54, DaleCurtis wrote:
> I wonder if we should have a if (!url.isHttpOrHttps()) return true here to
avoid
> any accidental blob/data urls ending with hls or mp4 extensions.

For HLS, this is kinda covered in IsHLSPath().

For mp4, I have no strong opinions. We can probably add this check in in "if"
statement one line 770.

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
content/renderer/render_frame_impl.cc:769: // software and hardware decoders are
not available.
On 2016/03/24 18:05:11, ddorwin wrote:
> s/hardware/platform/

Done.

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
content/renderer/render_frame_impl.cc:774: }
On 2016/03/24 18:09:10, DaleCurtis wrote:
> On 2016/03/24 at 18:05:11, ddorwin wrote:
> > On 2016/03/23 17:51:54, DaleCurtis wrote:
> > > On 2016/03/23 at 16:35:54, xhwang wrote:
> > > > ddorwin: So for HLS and .mp4 URL we'll still use mojo CDM if unified
> pipeline
> > > is enabled. I think this is fine because EME isn't supported in either
case
> > > anyways.
> > > 
> > > At least for mp4, this is only in the case that we don't have a
MediaCodec,
> so
> > > we couldn't play the mp4 even if EME was supported.
> > 
> > For HLS, it doesn't make sense to use EME, so that's fine.
> > 
> > For MP4, .src= does not work anywhere because of
> https://bugs.chromium.org/p/chromium/issues/detail?id=170793, so this is fine
> for now.
> > 
> > If we fixed that bug:
> > * Not having platform decoder support means (I believe) that MediaCodec is
not
> available or the GPU process is not working. The former means EME won't work
> anyway. The latter could work with WMPA, but I don't think it is an expected
> case. Dale?
> 
> Even if we "fixed" that bug for desktop/unified path, I don't think it would
> ever be fixed for MediaPlayer so that case seems impossible.
> 
> > * Clear Key doesn't need platform decoders, but we won't use Mojo CDM for
> that, right?

MojoCdmFactory actually support Clear Key [1]. This is how Clear Key works with
unified pipeline (so that we could use DDS to decrypt on the render side).

But even with that, we still need a decoder to decode MP4, which won't work in
the unified pipeline. So we are not breaking anything.

> > MimeUtil appears to be accurate (for H.264). When the unified pipeline is
> enabled, we require HasPlatformDecoderSupport() for encrypted content.
> > 
> > More generally, do we plan to continue to support EME in the WMPA path once
> we've fully switched to WMPI? Since MediaCodec is necessary, it would seem
that
> broken GPU process is the only case where we might fall back. (The current
> MimeUtil logic doesn't appear to report support in this case anyway.)
> 
> I expect we'll kill off the non-unified MSE paths very quickly (M53?) since
it's
> not needed for any blacklist or non-Chrome codecs.

Agreed. The non-unified EME path should go away too.


[1]
https://code.google.com/p/chromium/codesearch#chromium/src/media/mojo/service...

https://chromiumcodereview.appspot.com/1825763002/diff/1/media/base/media.cc
File media/base/media.cc (right):

https://chromiumcodereview.appspot.com/1825763002/diff/1/media/base/media.cc#...
media/base/media.cc:77: bool IsMojoCdmEnabled() {
On 2016/03/24 18:05:11, ddorwin wrote:
> Should this be ifdef'd to ENABLE_MOJO_CDMS?

Good point. Actually "media" should not know about "mojo media" at all. Also
ENABLE_MOJO_CDMS is defined in media/mojo so we can't use it here.

Since this is only used in RenderFrameImpl and there we have the best context,
moved this function to be a static function in RenderFrameImpl.

https://chromiumcodereview.appspot.com/1825763002/diff/1/media/base/media.h
File media/base/media.h (right):

https://chromiumcodereview.appspot.com/1825763002/diff/1/media/base/media.h#n...
media/base/media.h:52: 
On 2016/03/24 18:05:11, ddorwin wrote:
> Do we need a flag so we can selectively enable the new path for MSE separate
> from .src=?

OOC, why do you want this?

[ddorwin, 2016-03-24 21:43:50]

LGTM. Note that this CL means that the unified pipeline must be enabled/disabled
for all of .src=, MSE, and EME. We won't be able to revert (via the experiment)
MSE/EME back to WMPA without also reverting .src=.

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
File content/renderer/render_frame_impl.cc (right):

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
content/renderer/render_frame_impl.cc:774: }
On 2016/03/24 21:26:03, xhwang wrote:
> On 2016/03/24 18:09:10, DaleCurtis wrote:
> > On 2016/03/24 at 18:05:11, ddorwin wrote:
> > > On 2016/03/23 17:51:54, DaleCurtis wrote:
> > > > On 2016/03/23 at 16:35:54, xhwang wrote:
> > > > > ddorwin: So for HLS and .mp4 URL we'll still use mojo CDM if unified
> > pipeline
> > > > is enabled. I think this is fine because EME isn't supported in either
> case
> > > > anyways.
> > > > 
> > > > At least for mp4, this is only in the case that we don't have a
> MediaCodec,
> > so
> > > > we couldn't play the mp4 even if EME was supported.
> > > 
> > > For HLS, it doesn't make sense to use EME, so that's fine.
> > > 
> > > For MP4, .src= does not work anywhere because of
> > https://bugs.chromium.org/p/chromium/issues/detail?id=170793, so this is
fine
> > for now.
> > > 
> > > If we fixed that bug:
> > > * Not having platform decoder support means (I believe) that MediaCodec is
> not
> > available or the GPU process is not working. The former means EME won't work
> > anyway. The latter could work with WMPA, but I don't think it is an expected
> > case. Dale?
> > 
> > Even if we "fixed" that bug for desktop/unified path, I don't think it would
> > ever be fixed for MediaPlayer so that case seems impossible.
> > 
> > > * Clear Key doesn't need platform decoders, but we won't use Mojo CDM for
> > that, right?
> 
> MojoCdmFactory actually support Clear Key [1]. This is how Clear Key works
with
> unified pipeline (so that we could use DDS to decrypt on the render side).
> 
> But even with that, we still need a decoder to decode MP4, which won't work in
> the unified pipeline. So we are not breaking anything.

Unencrypted or Clear Key AAC does not require a decoder. Also,
https://bugs.chromium.org/p/chromium/issues/detail?id=580623.
> 
> > > MimeUtil appears to be accurate (for H.264). When the unified pipeline is
> > enabled, we require HasPlatformDecoderSupport() for encrypted content.
> > > 
> > > More generally, do we plan to continue to support EME in the WMPA path
once
> > we've fully switched to WMPI? Since MediaCodec is necessary, it would seem
> that
> > broken GPU process is the only case where we might fall back. (The current
> > MimeUtil logic doesn't appear to report support in this case anyway.)
> > 
> > I expect we'll kill off the non-unified MSE paths very quickly (M53?) since
> it's
> > not needed for any blacklist or non-Chrome codecs.
> 
> Agreed. The non-unified EME path should go away too.
> 
> 
> [1]
>
https://code.google.com/p/chromium/codesearch#chromium/src/media/mojo/service...

[wolenetz, 2016-03-24 22:16:25]

wolenetz@chromium.org changed reviewers:
+ wolenetz@chromium.org

[wolenetz, 2016-03-24 22:16:26]

lgtm !!
To David's point, with this CL, if we need to differentiate unified EME/MSE
support vs unified src= support, we would need a code change and not just a
field trial rate change.

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
File content/renderer/render_frame_impl.cc (right):

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
content/renderer/render_frame_impl.cc:763: bool UseWebMediaPlayerImpl(const
GURL& url) {
On 2016/03/24 21:26:04, xhwang wrote:
> On 2016/03/23 17:51:54, DaleCurtis wrote:
> > I wonder if we should have a if (!url.isHttpOrHttps()) return true here to
> avoid
> > any accidental blob/data urls ending with hls or mp4 extensions.
> 
> For HLS, this is kinda covered in IsHLSPath().
> 
> For mp4, I have no strong opinions. We can probably add this check in in "if"
> statement one line 770.

There should be no blob URL containing trailing .mp4 (or .m3u8). I think it'd be
incorrect currently for a properly formatted blob URL [1] [2] to have a 
trailing ".mp4" or (or ".m3u8"), since [.mpu] chars are not allowed within the
UUID portion of such a URL [3]. Otherwise, no strong opinion. We could
potentially protect against those specs changing by strengthening line 770. 

[1] code:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...
[2] FILE API spec: https://www.w3.org/TR/FileAPI/#unicodeBlobURL
[3] RFC for the UUID portion of a blob URL: https://tools.ietf.org/html/rfc4122

[xhwang, 2016-03-24 22:37:23]

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
File content/renderer/render_frame_impl.cc (right):

https://chromiumcodereview.appspot.com/1825763002/diff/1/content/renderer/ren...
content/renderer/render_frame_impl.cc:774: }
> Unencrypted or Clear Key AAC does not require a decoder. Also,
> https://bugs.chromium.org/p/chromium/issues/detail?id=580623.

Good catch. We'll need to detect more to fix these cases. But I don't know
whether it's worth the effort.

[xhwang, 2016-03-24 22:39:13]

xhwang@chromium.org changed reviewers:
+ pfeldman@chromium.org

[xhwang, 2016-03-24 22:39:14]

pfeldman@chromium.org: Please OWNERS review changes in content/renderer and
third_party/WebKit.

[xhwang, 2016-03-25 06:27:20]

Description was changed from

==========
media: Enable Unified Media Pipeline for MSE and EME on Android

Enables Mojo Media on Android to support EME in the unified media
pipeline. This introduces MojoCdm, MojoAudioDecoder and encrytped
stream support in AndroidVideoDecodeAccelerator.

This CL also enables MSE in the unified media pipeline. The fallback
logic for MSE (IsUnifiedMediaPipelineEnabledForMse()) is removed.

Also partially reverts f92f4e5c849c028db73fbe06912685a77b978ee4 which
added "LoadType" in createMediaPlayer() to implement the fallback
logic for MSE.

BUG=521731
TEST=Encrypted audio/video plays in default Chrome for Android build
with and without unified media pipeline.
==========

to

==========
media: Enable Unified Media Pipeline for MSE and EME on Android

Enables Mojo Media on Android to support EME in the unified media
pipeline. This introduces MojoCdm, MojoAudioDecoder and encrytped
stream support in AndroidVideoDecodeAccelerator.

This CL also enables MSE in the unified media pipeline. The fallback
logic for MSE (IsUnifiedMediaPipelineEnabledForMse()) is removed.

Also partially reverts f92f4e5c849c028db73fbe06912685a77b978ee4 which
added "LoadType" in createMediaPlayer() to implement the fallback
logic for MSE.

BUG=455905,521731
TEST=Encrypted audio/video plays in default Chrome for Android build
with and without unified media pipeline.
==========

[xhwang, 2016-03-25 08:41:35]

The CQ bit was checked by xhwang@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-25 08:41:43]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1825763002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1825763002/20001

[commit-bot: I haz the power, 2016-03-25 09:23:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-25 09:23:48]

Dry run: Try jobs failed on following builders:
  android_chromium_gn_compile_rel on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_chro...)

[pfeldman, 2016-03-25 17:48:04]

lgtm

[xhwang, 2016-03-25 17:52:11]

The CQ bit was checked by xhwang@chromium.org

[xhwang, 2016-03-25 17:52:11]

The patchset sent to the CQ was uploaded after l-g-t-m from
dalecurtis@chromium.org, ddorwin@chromium.org, wolenetz@chromium.org
Link to the patchset: https://chromiumcodereview.appspot.com/1825763002/#ps40001
(title: "fix")

[commit-bot: I haz the power, 2016-03-25 17:52:37]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1825763002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1825763002/40001

[commit-bot: I haz the power, 2016-03-25 19:32:28]

Description was changed from

==========
media: Enable Unified Media Pipeline for MSE and EME on Android

Enables Mojo Media on Android to support EME in the unified media
pipeline. This introduces MojoCdm, MojoAudioDecoder and encrytped
stream support in AndroidVideoDecodeAccelerator.

This CL also enables MSE in the unified media pipeline. The fallback
logic for MSE (IsUnifiedMediaPipelineEnabledForMse()) is removed.

Also partially reverts f92f4e5c849c028db73fbe06912685a77b978ee4 which
added "LoadType" in createMediaPlayer() to implement the fallback
logic for MSE.

BUG=455905,521731
TEST=Encrypted audio/video plays in default Chrome for Android build
with and without unified media pipeline.
==========

to

==========
media: Enable Unified Media Pipeline for MSE and EME on Android

Enables Mojo Media on Android to support EME in the unified media
pipeline. This introduces MojoCdm, MojoAudioDecoder and encrytped
stream support in AndroidVideoDecodeAccelerator.

This CL also enables MSE in the unified media pipeline. The fallback
logic for MSE (IsUnifiedMediaPipelineEnabledForMse()) is removed.

Also partially reverts f92f4e5c849c028db73fbe06912685a77b978ee4 which
added "LoadType" in createMediaPlayer() to implement the fallback
logic for MSE.

BUG=455905,521731
TEST=Encrypted audio/video plays in default Chrome for Android build
with and without unified media pipeline.
==========

[commit-bot: I haz the power, 2016-03-25 19:32:30]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-03-25 19:38:49]

Description was changed from

==========
media: Enable Unified Media Pipeline for MSE and EME on Android

Enables Mojo Media on Android to support EME in the unified media
pipeline. This introduces MojoCdm, MojoAudioDecoder and encrytped
stream support in AndroidVideoDecodeAccelerator.

This CL also enables MSE in the unified media pipeline. The fallback
logic for MSE (IsUnifiedMediaPipelineEnabledForMse()) is removed.

Also partially reverts f92f4e5c849c028db73fbe06912685a77b978ee4 which
added "LoadType" in createMediaPlayer() to implement the fallback
logic for MSE.

BUG=455905,521731
TEST=Encrypted audio/video plays in default Chrome for Android build
with and without unified media pipeline.
==========

to

==========
media: Enable Unified Media Pipeline for MSE and EME on Android

Enables Mojo Media on Android to support EME in the unified media
pipeline. This introduces MojoCdm, MojoAudioDecoder and encrytped
stream support in AndroidVideoDecodeAccelerator.

This CL also enables MSE in the unified media pipeline. The fallback
logic for MSE (IsUnifiedMediaPipelineEnabledForMse()) is removed.

Also partially reverts f92f4e5c849c028db73fbe06912685a77b978ee4 which
added "LoadType" in createMediaPlayer() to implement the fallback
logic for MSE.

BUG=455905,521731
TEST=Encrypted audio/video plays in default Chrome for Android build
with and without unified media pipeline.

Committed: https://crrev.com/92d0fffc36695c099005bf05862145a89d918f28
Cr-Commit-Position: refs/heads/master@{#383331}
==========

[commit-bot: I haz the power, 2016-03-25 19:38:51]

Patchset 3 (id:??) landed as
https://crrev.com/92d0fffc36695c099005bf05862145a89d918f28
Cr-Commit-Position: refs/heads/master@{#383331}

[gone, 2016-03-25 23:43:15]

A revert of this CL (patchset #3 id:40001) has been created in
https://chromiumcodereview.appspot.com/1840563002/ by dfalcantara@chromium.org.

The reason for reverting is: Android tests on many bots started failing right
after this; these are the most obvious:

https://build.chromium.org/p/chromium.android/builders/Lollipop%20Phone%20Tes...
* RenderFrameImplTest.LoFiNotUpdatedOnSubframeCommits
* RenderViewImplTest.OnSetAccessibilityMode

I reverted locally multiple times to make sure, but
RenderFrameImplTest.LoFiNotUpdatedOnSubframeCommits only starts failing when
this CL is committed, AFAICT..

[aayron003, 2016-10-02 11:40:34]

aayron003@gmail.com changed reviewers:
+ aayron003@gmail.com

[aayron003, 2016-10-02 11:40:36]

lgtm