Open vi-dot-cpp opened 4 years ago
I still support :). @mounirlamouri - any feedback?
I have a hard time to understand what the proposal is trying to do. Are we suggesting to check the supported configuration
back?
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:
MediaKeySystemAccess.getConfiguration()
is not problematic for MediaCapabilities.decodingInfo()
as the input is a single configuration as opposed to a vector of configurations.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.MediaKeySystemConfiguration
, which I am aiming to avoid.Let me know if I've misunderstood your question -- thanks.
2.3.3. Check Encrypted Decoding Support algorithm only checks the CDM for
MediaKeySystemConfiguration
support. This assumes that clear and protected modes share the sameMediaConfiguration
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 checkMediaConfiguration
.Ideally this could be achieved while maintaining MC's dependency on EME and impacting EME minimally. After discussion, chcunningham@ suggested the following:
What are your thoughts?