Add consideration for MediaDecodingConfiguration to 2.3.3. Check Encrypted Decoding Support algorithm

[vi-dot-cpp]

2.3.3. Check Encrypted Decoding Support algorithm only checks the CDM for MediaKeySystemConfiguration support. This assumes that clear and protected modes share the same MediaConfiguration capabilities.

In Edge, the PlayReady CDM renders encrypted content using a different renderer than the Chromium renderer, thus creating a need for EME MC.decodingInfo() to additionally check MediaConfiguration.

Ideally this could be achieved while maintaining MC's dependency on EME and impacting EME minimally. After discussion, chcunningham@ suggested the following:

(MC Spec) 2.3.3. Check Encrypted Decoding Support
Steps 1 - 6: as-is
Insert new step 7: "Additionally, check that implementation supports decoding for attributes of configuration not found in emeConfiguration. If any attribute is unsupported, return null and abort these steps."
Existing step 7 and 8 shift down to become steps 8 and 9.

Rationale: I'm trying to stay roughly consistent with how we spec'ed supported = true for the non EME case. "If the user agent is able to decode the media represented by configuration, set supported to true." This also has the nice property that's its very succinct!

What are your thoughts?

[chcunningham]

I still support :). @mounirlamouri - any feedback?

[mounirlamouri]

I have a hard time to understand what the proposal is trying to do. Are we suggesting to check the supported configuration back?

[vi-dot-cpp]

Are we suggesting to check the supported configuration back?

I understand the proposal, in essence, to mean that supported configuration is to be the combined result of the Get Supported Configuration algorithm and the proposed step 7.

supported configuration is NotSupported if either step so indicates.

If both steps indicate support, I'm not planning for MediaConfiguration-specific configurations to be reflected in supported configuration and be part of MediaKeySystemAccess because:

1. The ambiguity that necessitates MediaKeySystemAccess.getConfiguration() is not problematic for MediaCapabilities.decodingInfo() as the input is a single configuration as opposed to a vector of configurations.
2. MediaKeySystemAccess.getConfiguration() calls out that "the returned object is a non-strict subset...and thus may not reflect all capabilities of the Key System implementation." I interpet this to mean that sites know there can be gaps.
3. Doing so likely requires spec edits to MediaKeySystemConfiguration, which I am aiming to avoid.

Let me know if I've misunderstood your question -- thanks.