New issue
Advanced search Search tips

Issue 724362 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

EME codec and init data type query cleanup

Project Member Reported by xhw...@chromium.org, May 19 2017

Issue description

This is a summary of what's discussed in https://chromiumcodereview.appspot.com/2881443002/, mostly from ddorwin's comments. (Thanks!).

1, In EmeCodec, remove the container type, e.g. EME_CODEC_WEBM_OPUS -> EME_CODEC_OPUS.

2. COMMON_VP9 should be just VP9, and WEBM_VP9 should be VP9_LEGACY. For now we still need these two VP9 enums because most CDMs supports VP9_LEGAY (vp9), but support of VP9 (vp09) is still in development, e.g. for profile 2/3.

3. On Android, we query a combination of codec and container mime type (e.g. vp9 and video/webm). However, the real purpose of the container mime type query is to know whether certain initdata type is supported (e.g. webm) for a key system. And AndroidPlatformKeySystemProperties::IsSupportedInitDataType() abuses the container part of an EmeCodec. We should explicitly query initdata type support, which should be independent of codec support query. Also see issue 589521.

4 There are some things we should clean up in key_systems.cc:
* kCodecStrings probably doesn't need separate enum values. It is used to convert strings to an enum.
* We can remove vp8.0 and vp9.0 from that table because the strings are stripped.
* That table should be renamed to include "Stripped" or similar.
* The name of codec_string_map_ and parameters that are passed to methods that use it should also be updated.


 
Regarding (2):

I believe the two VP9 enums are only used to specify the string format that is accepted by a container. The fact that the vp09 format is supported does not indicate support for other profiles.

Since we now use MimeUtil to perform content type string checks, I don't think we need this difference at all. We have tests that should catch any such issues (assuming they were updated to include the new vp09 format in positive and negative tests).

We do need a mechanism for CDM implementations to advertise specific profiles, bit-depths, etc., starting with VP9 but also for some proprietary codecs. We should follow and/or build on the general work being done to add such checks for platform codecs.
Labels: Target-70
While I am looking at EME query code, I'll look at this.
Labels: -Target-70 Target-71
Labels: M-71
Labels: M-70
Labels: -M-70
Labels: -M-71 -Target-71 Target-72 M-72
Status: Started (was: Assigned)
Labels: -M-72 -Target-72
Status: Assigned (was: Started)

Sign in to add a comment