Intent to Implement: MediaCapabilities: encrypted (EME) decodingInfo()
Chris Cunningham
Contact emails
chcunn...@chromium.org, mlam...@chromium.org, hben...@chromium.org
Explainer
https://github.com/WICG/media-capabilities/blob/master/explainer.md#encryption
Spec
Links to design doc and spec, if and when available.
https://wicg.github.io/media-capabilities/#is-encrypted-decode-supported
Tag review for the initial API shape here. I’ve given heads up for the updates for encrypted media.
https://github.com/w3ctag/design-reviews/issues/218#issuecomment-448408971
Summary
We previously shipped `mediaCapabilities.decodingInfo()` for unencrypted media. Web authors can call this API with a dictionary describing their media configuration to determine if decoding is supported and whether it will be smooth (timely) and/or power efficient.
The specification has since been updated with additional inputs and algorithms to describe encrypted media. This intent tracks implementing those additions.
Encrypted media playback is still described solely by the EME specification. MediaCapabilities takes a normative dependency on EME to reference EME type definitions and algorithms.
Motivation
Encrypted media requires a description what Key System will be used and how it is configured. Given this configuration, decoding generally uses different code paths and resources. This alters what media configurations are supported and their performance vs clear content.
Risks
Interoperability and Compatibility
Edge: No signals
Firefox: Public support
Safari: No signals
Web / Framework developers: Positive
Ergonomics
This API will frequently be used in tandem with EME.
Today’s EME flow begins with a call to requestMediaKeySystemAccess(). This existing API takes in an ordered list of basic media content types and returns (via promise) a MediaKeySystemAccess for the subset of types that can be supported. From there, callers use the MediaKeySystemAccess.createMediaKeys() to setup the encrypted playback.
After implementing the proposal above, web authors can instead use MediaCapabilities.decodingInfo() to acquire a MediaKeySystemAccess alongside additional MediaCapabilitiesInfo fields that signal when the decoding will be smooth and/or power efficient. Authors can then use the MediaKeySystemAccess to setup the encrypted playback in the same way they do today.
Activation
No polyfills needed, though one may be nice to have. Several libraries exist to help setup EME playback. These can be easily amended to call MediaCapabilities.decodingInfo() where desired.
Major browsers support MediaCapabilities.decodingInfo(), but most will not yet support the additional dictionary members that describe encrypted media. Web authors can detect when these fields are ignored by observing that the returned MediaCapabilitiesInfo does not contain a MediaKeySystemAccess while reporting supported=true (i.e. the UA replied as if the configuration described unencrypted media).
Debuggability
Existing dev tools (JavaScript debugger) will work well.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5765900795904000
Requesting approval to ship?
No.
Joe Medley
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6eSpC93%3D9FDeLgRvyVyTn6ieAyWJCaxoGy2EFeSM4kD8Oag%40mail.gmail.com.