Implement support for vp9 in ISO-BMFF

media/base/eme_constants.h

Index: media/base/eme_constants.h
diff --git a/media/base/eme_constants.h b/media/base/eme_constants.h
index ba49c7d6a72d9e3307f64449ee37d4821550ce00..1d973d202d3f62f943095f823763a8835f9840ee 100644
--- a/media/base/eme_constants.h
+++ b/media/base/eme_constants.h
@@ -44,7 +44,10 @@ enum EmeCodec {
   EME_CODEC_MP4_AAC = 1 << 4,
   EME_CODEC_MP4_AUDIO_ALL = EME_CODEC_MP4_AAC,
   EME_CODEC_MP4_AVC1 = 1 << 5,
-  EME_CODEC_MP4_VIDEO_ALL = EME_CODEC_MP4_AVC1,
+  EME_CODEC_MP4_VP8 = 1 << 6,

[ddorwin, 2016/01/27 01:39:14]

Is this actually going to be used? If not or we don't know, perhaps we should
only support VP9 for now.

[kqyang, 2016/01/29 00:34:16]

I don't know, but why not, it does not require a lot of effort to support it.

That said, I am fine with removing VP8 support if you have a strong opinion on
this.

+  EME_CODEC_MP4_VP9 = 1 << 7,

[ddorwin, 2016/01/27 01:39:14]

Do we need separate codec enums? I know these are currently tied to containers
and we have <container>_ALL values, but is that necessary? I have always been
concerned about the _ALL values (see below), and at least one use appears to be
obsolete (see next file).

[ddorwin, 2016/01/27 03:17:09]

Of course, we also rely on this difference here:
https://code.google.com/p/chromium/codesearch#chromium/src/components/cdm/ren...

However, I'm not sure the Android code will ever set MP4_VP9 as this CL
currently stands.

There are a lot of corner cases exposed by allowing codecs in different
containers, and it appears to be too difficult to reason about them at the
moment. Perhaps we should address the technical debt that makes assumptions
about codecs, containers, and initialization data types. With the removal of
prefixed EME, it might be possible to remove some of these (see the TODO in the
next file).

[ddorwin, 2016/01/27 06:42:56]

Specifically, we can address the Android case by adding initDataTypes to
SupportedKeySystemResponse. We need to do that anyway if we ever want to support
keyids.

xhwang: Is there a Mojo interface that will replace this Android-specific query?

Alternatively, there is https://crbug.com/457438, which would change all of
this.

[xhwang, 2016/02/01 17:59:37]

Currently the mojo work is focusing mainly on the core EME stack (MediaKeys
interface and implementations). We don't have any plan to convert the key system
(and codec) support query over render-browser IPC yet.

+  EME_CODEC_MP4_VIDEO_ALL =

[ddorwin, 2016/01/27 01:39:14]

Not all platforms that support MP4 necessarily support VPx [in MP4]. If these
_ALL values are used incorrectly during registration, support could be
incorrectly advertised. (These _ALL values should be eliminated or somehow made
internal to media/.)

For example,
https://code.google.com/p/chromium/codesearch#chromium/src/components/cdm/ren...
and
https://code.google.com/p/chromium/codesearch#chromium/src/components/cdm/ren....

If we do care about the container a codec supports, we will need specific
checks. If not, we can rely on container validity checks (for clear content)
along with initDataType checks for whether the CDM can generate license
requests.

[kqyang, 2016/01/29 00:34:16]

Aren't these _ALL values just a list of all possible codecs in EME? Whether a
particular codec is supported or not is determined by the platform specific
code, and if supported, will be available in KeySystemInfo::supported_codecs.
I don't see a problem in the examples above. mp4 uses pssh as init_data. If any
of the mp4 codec is supported, it should support pssh init_data.

[ddorwin, 2016/02/24 22:44:32]

Yes, those specific examples are fine, but that code should not have access to
them. I filed https://bugs.chromium.org/p/chromium/issues/detail?id=589515.

+      (EME_CODEC_MP4_AVC1 | EME_CODEC_MP4_VP8 | EME_CODEC_MP4_VP9),
   EME_CODEC_MP4_ALL = (EME_CODEC_MP4_AUDIO_ALL | EME_CODEC_MP4_VIDEO_ALL),
   EME_CODEC_AUDIO_ALL = (EME_CODEC_WEBM_AUDIO_ALL | EME_CODEC_MP4_AUDIO_ALL),
   EME_CODEC_VIDEO_ALL = (EME_CODEC_WEBM_VIDEO_ALL | EME_CODEC_MP4_VIDEO_ALL),