Check HTMLMediaElement::supportsType() in MediaSource.isTypeSupported()

Check HTMLMediaElement::supportsType() in MediaSource.isTypeSupported()

MediaSource.isTypeSupported() should not return true without making sure
that the HTMLMediaElement supports the content type as well.

BUG=402386
R=acolwell@chromium.org

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=180035

[philipj_slow, 2014-08-11 09:19:10]

I've reviewed this internally and it seems reasonable, but I'm not knowledgeable
enough about the backends to say if it's fixing the problem at the right level.

With vanilla Chromium, I'm guessing there doesn't exist any format that's
supported using MSE but which isn't supported using plain HTMLMediaElement?
That's the scenario here.

[acolwell GONE FROM CHROMIUM, 2014-08-11 18:04:09]

lgtm. Is there a specific bug that is being fixed here or is this just making
the code consistant with the spec note?

[philipj_slow, 2014-08-11 19:38:57]

Henrik has the details, but there was apparently a real scenario on our Devices
SDK product where one container format (probably WebM) was supported as a
chunked demuxer but the WebMediaPlayer backend didn't support it. (Like on
Android, integrating with the platform media framework is sometimes the only
practical option, which leaves format support outside of our control.)

I'm guessing that there's no way to get this situation with WebMediaPlayerMS +
WebMediaPlayerImpl.

[Henrik Steen, 2014-08-11 19:57:18]

On 2014/08/11 19:38:57, philipj wrote:
> Henrik has the details, but there was apparently a real scenario on our
Devices
> SDK product where one container format (probably WebM) was supported as a
> chunked demuxer but the WebMediaPlayer backend didn't support it. (Like on
> Android, integrating with the platform media framework is sometimes the only
> practical option, which leaves format support outside of our control.)
> 
> I'm guessing that there's no way to get this situation with WebMediaPlayerMS +
> WebMediaPlayerImpl.

Yes, the the problem we (in TV/Devices) had was that the MSE chunkdemuxer in
Chromium could claim to support content that the video backend on some platform
wasn't able to handle.  Like mobile phones, most TVs aren't powerful enough to
have fallback decoding &c in software, so if the platform doesn't support WebM
(for example) the MediaSource.isTypeSupported() could give a false impression of
support.

[Henrik Steen, 2014-08-12 05:01:10]

The CQ bit was checked by henriks@opera.com

[commit-bot: I haz the power, 2014-08-12 05:01:43]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/henriks@opera.com/456313003/1

[commit-bot: I haz the power, 2014-08-12 05:38:22]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  linux_blink_dbg on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/linux_blink_dbg/builds/2...)
  linux_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/2...)
  mac_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/mac_blink_rel/builds/19388)
  win_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/win_blink_rel/builds/22185)

[commit-bot: I haz the power, 2014-08-12 06:41:47]

Change committed as 180035