media/base/eme_constants.h - Issue 1624703002: Implement support for vp9 in ISO-BMFF

Side by Side Diff: media/base/eme_constants.h

Issue 1624703002: Implement support for vp9 in ISO-BMFF (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: Created 4 years, 11 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

OLD	NEW
1 // Copyright 2014 The Chromium Authors. All rights reserved.	1 // Copyright 2014 The Chromium Authors. All rights reserved.

2 // Use of this source code is governed by a BSD-style license that can be	2 // Use of this source code is governed by a BSD-style license that can be

3 // found in the LICENSE file.	3 // found in the LICENSE file.

4	4

5 #ifndef MEDIA_BASE_EME_CONSTANTS_H_	5 #ifndef MEDIA_BASE_EME_CONSTANTS_H_

6 #define MEDIA_BASE_EME_CONSTANTS_H_	6 #define MEDIA_BASE_EME_CONSTANTS_H_

7	7

8 #include <stdint.h>	8 #include <stdint.h>

9	9

10 namespace media {	10 namespace media {

(...skipping 26 matching lines...) Expand all Loading...
37 EME_CODEC_WEBM_VORBIS = 1 << 1,	37 EME_CODEC_WEBM_VORBIS = 1 << 1,

38 EME_CODEC_WEBM_AUDIO_ALL = EME_CODEC_WEBM_OPUS \| EME_CODEC_WEBM_VORBIS,	38 EME_CODEC_WEBM_AUDIO_ALL = EME_CODEC_WEBM_OPUS \| EME_CODEC_WEBM_VORBIS,

39 EME_CODEC_WEBM_VP8 = 1 << 2,	39 EME_CODEC_WEBM_VP8 = 1 << 2,

40 EME_CODEC_WEBM_VP9 = 1 << 3,	40 EME_CODEC_WEBM_VP9 = 1 << 3,

41 EME_CODEC_WEBM_VIDEO_ALL = (EME_CODEC_WEBM_VP8 \| EME_CODEC_WEBM_VP9),	41 EME_CODEC_WEBM_VIDEO_ALL = (EME_CODEC_WEBM_VP8 \| EME_CODEC_WEBM_VP9),

42 EME_CODEC_WEBM_ALL = (EME_CODEC_WEBM_AUDIO_ALL \| EME_CODEC_WEBM_VIDEO_ALL),	42 EME_CODEC_WEBM_ALL = (EME_CODEC_WEBM_AUDIO_ALL \| EME_CODEC_WEBM_VIDEO_ALL),

43 #if defined(USE_PROPRIETARY_CODECS)	43 #if defined(USE_PROPRIETARY_CODECS)

44 EME_CODEC_MP4_AAC = 1 << 4,	44 EME_CODEC_MP4_AAC = 1 << 4,

45 EME_CODEC_MP4_AUDIO_ALL = EME_CODEC_MP4_AAC,	45 EME_CODEC_MP4_AUDIO_ALL = EME_CODEC_MP4_AAC,

46 EME_CODEC_MP4_AVC1 = 1 << 5,	46 EME_CODEC_MP4_AVC1 = 1 << 5,

47 EME_CODEC_MP4_VIDEO_ALL = EME_CODEC_MP4_AVC1,	47 EME_CODEC_MP4_VP8 = 1 << 6,
	ddorwin 2016/01/27 01:39:14 Is this actually going to be used? If not or we do 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 l Show quoted text On 2016/01/27 01:39:14, ddorwin wrote: > Is this actually going to be used? If not or we don't know, perhaps we should > only support VP9 for now. 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.
	48 EME_CODEC_MP4_VP9 = 1 << 7,
	ddorwin 2016/01/27 01:39:14 Do we need separate codec enums? I know these are 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: h Show quoted text On 2016/01/27 01:39:14, ddorwin wrote: > 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). 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 a Show quoted text On 2016/01/27 03:17:09, ddorwin wrote: > On 2016/01/27 01:39:14, ddorwin wrote: > > 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). > > 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). 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 Show quoted text On 2016/01/27 06:42:56, ddorwin wrote: > On 2016/01/27 03:17:09, ddorwin wrote: > > On 2016/01/27 01:39:14, ddorwin wrote: > > > 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). > > > > 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). > > 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. 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.
	49 EME_CODEC_MP4_VIDEO_ALL =
	ddorwin 2016/01/27 01:39:14 Not all platforms that support MP4 necessarily sup 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 possib Show quoted text On 2016/01/27 01:39:14, ddorwin wrote: > 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/.) 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. Show quoted text > > 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.... 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. Show quoted text > > 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. ddorwin 2016/02/24 22:44:32 Yes, those specific examples are fine, but that co Show quoted text On 2016/01/29 00:34:16, kqyang wrote: > On 2016/01/27 01:39:14, ddorwin wrote: > > 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/.) > > 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. > > > > > 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.... > > > 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. > > > > > 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. 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.
	50 (EME_CODEC_MP4_AVC1 \| EME_CODEC_MP4_VP8 \| EME_CODEC_MP4_VP9),

48 EME_CODEC_MP4_ALL = (EME_CODEC_MP4_AUDIO_ALL \| EME_CODEC_MP4_VIDEO_ALL),	51 EME_CODEC_MP4_ALL = (EME_CODEC_MP4_AUDIO_ALL \| EME_CODEC_MP4_VIDEO_ALL),

49 EME_CODEC_AUDIO_ALL = (EME_CODEC_WEBM_AUDIO_ALL \| EME_CODEC_MP4_AUDIO_ALL),	52 EME_CODEC_AUDIO_ALL = (EME_CODEC_WEBM_AUDIO_ALL \| EME_CODEC_MP4_AUDIO_ALL),

50 EME_CODEC_VIDEO_ALL = (EME_CODEC_WEBM_VIDEO_ALL \| EME_CODEC_MP4_VIDEO_ALL),	53 EME_CODEC_VIDEO_ALL = (EME_CODEC_WEBM_VIDEO_ALL \| EME_CODEC_MP4_VIDEO_ALL),

51 EME_CODEC_ALL = (EME_CODEC_WEBM_ALL \| EME_CODEC_MP4_ALL),	54 EME_CODEC_ALL = (EME_CODEC_WEBM_ALL \| EME_CODEC_MP4_ALL),

52 #else	55 #else

53 EME_CODEC_AUDIO_ALL = EME_CODEC_WEBM_AUDIO_ALL,	56 EME_CODEC_AUDIO_ALL = EME_CODEC_WEBM_AUDIO_ALL,

54 EME_CODEC_VIDEO_ALL = EME_CODEC_WEBM_VIDEO_ALL,	57 EME_CODEC_VIDEO_ALL = EME_CODEC_WEBM_VIDEO_ALL,

55 EME_CODEC_ALL = EME_CODEC_WEBM_ALL,	58 EME_CODEC_ALL = EME_CODEC_WEBM_ALL,

56 #endif // defined(USE_PROPRIETARY_CODECS)	59 #endif // defined(USE_PROPRIETARY_CODECS)

57 };	60 };

(...skipping 79 matching lines...) Expand 10 before \| Expand all \| Expand 10 after Loading...
137 // This rule only has meaning on platforms that distinguish hardware-secure	140 // This rule only has meaning on platforms that distinguish hardware-secure

138 // codecs (ie. Android).	141 // codecs (ie. Android).

139 HW_SECURE_CODECS_REQUIRED,	142 HW_SECURE_CODECS_REQUIRED,

140 // The configuration option is supported without conditions.	143 // The configuration option is supported without conditions.

141 SUPPORTED,	144 SUPPORTED,

142 };	145 };

143	146

144 } // namespace media	147 } // namespace media

145	148

146 #endif // MEDIA_BASE_EME_CONSTANTS_H_	149 #endif // MEDIA_BASE_EME_CONSTANTS_H_

OLD	NEW

« chrome/renderer/media/chrome_key_systems.cc ('K') | « chrome/renderer/media/chrome_key_systems.cc ('k') | media/base/key_systems.cc » ('j') | media/base/key_systems.cc » ('J')