Specification Changes
The specifications for both Media Source Extensions (MSE) and Encrypted Media Extensions (EME) are still in development. Microsoft first supported them in Internet Explorer 11 on Windows 8.1, using an “ms” prefix for the EME APIs to denote they were likely to change. Since that time, the EME spec has added new APIs for requesting keySystem access and new operations supported under MediaKeySession, among other changes. These have been implemented in Microsoft Edge on Windows 10 PCs and, for the first time, Windows phones.
Both prefixed and the new unprefixed APIs are supported in Microsoft Edge, while IE11 has prefixed support only. This means that a website built to use the prefixed API will continue to work on Microsoft Edge and IE11. Websites that use the unprefixed APIs should work on Microsoft Edge, but developers should verify their implementations on Edge to confirm this. There are some details that require developer attention to achieve interoperable EME. There’s more on this below.
Multiple DRM Providers
EME was designed to support multiple Digital Rights Management (DRM) providers (“keySystems”) using Content Decryption Modules. The API itself is intended to be DRM neutral. Each browser that supports EME has implemented at least one CDM.
A key underpinning that makes this work is the development of ISO MPEG Common Encryption. By using common encryption, web media services can set up uniform content libraries that are compatible with more than one DRM solution. A service can choose to support more than one DRM without having to encrypt content for each individual DRM.
In practice, this means that websites encrypt files once, and support one or more DRM license servers to enable playback on individual web browsers. So, they can support a PlayReady DRM license server to enable playback on IE11, Microsoft Edge or non-Windows browser which supports a PlayReady CDM; and other DRM license servers (Widevine, Adobe Access, FairPlay, etc…) to enable playback on other browsers. This ability to have one encrypted library work with multiple keySystems is an important feature of EME. Websites must though include some code for each keySystem and browser combination the designers wish to support.
Interoperable Demo
To demonstrate these concepts, we’ve updated our Professional Quality Video demo from three years ago.We had two goals for this update:
- Implement prefixed/unprefixed EME selection so that the demo works properly on existing IE11 browsers using the prefixed API, and on Microsoft Edge using the updated unprefixed API.
- Implement keySystem switching to allow the demo to run on Microsoft browsers and other browsers.
Microsoft Azure Media Services hosts the content for our demo. Azure Media Services allows you to get PlayReady or Widevine (the keySystem that is supported natively in Google Chrome) licenses from the cloud and stream multi-DRM protected content to various platforms and devices. This provided the opportunity to expand our demo so that it works either on Microsoft browsers using PlayReady DRM or Chrome using Widevine.
Please refer to Using PlayReady and/or Widevine dynamic common encryption for more information on how to use different content protection systems with Azure Media Services.
The following sections explain key implementation points from the Professional Quality Video Updated – Interoperable Playback demo.
Detect Updated EME
The demo first needs to determine what version of EME is available. In the code below, we feature detect to see if requestMediaKeySystemAccess is supported, and use that as an indicator for the updated EME support in the browser:
https://gist.github.com/kypflug/d19b846047e0b41bad12
The demo elects to use the unprefixed EME when it is available, but the choice here is up to the webpage developers. Unprefixed EME doesn’t isolate the browser to Microsoft Edge only. For our supported browser set, it could be either Microsoft Edge or Chrome.
Detect keySystem
Next, we call requestMediaKeySystemAccess with a PlayReady configuration that has its keySystem string and formats we’d like to play. This API is implemented as a Promise. If PlayReady isn’t supported, the Promise is rejected. If that happens, we call requestMediaKeySystemAccess again, but this time with a Widevine configuration. If that Promise is rejected, then no playback of protected media is possible for our demo. A successful Promise return on either configuration means playback can proceed with the supported keySystem. Here’s a code snippet that demonstrates this:
https://gist.github.com/kypflug/b78e8973bfced8b09845
Accommodate DRM Specifics
A key difference between PlayReady and Widevine involves how the DRM challenge is handled. For PlayReady, the challenge must be parsed from the XML returned by the EME onmessage event and the app must then set the header values to fetch the key via XMLHttpRequest. This works the same as the prefixed EME support for PlayReady:
https://gist.github.com/kypflug/b41b93681373c1433d88
Something else to notice is the way the license URL is used between prefixed EME and unprefixed EME. In prefixed EME, the license server URL is passed to the onmskeymessage event. In unprefixed EME, the website needs to supply the license server URL directly.
Conclusion
Media Source Extensions and Encrypted Media Extensions continue to be the best option for website developers that want to support streaming media on a broad range of browsers and devices. We’ve updated our demo to provide help accomplishing this. Please send us your feedback so we can further improve our media support in Microsoft Edge!
– Jesse Mohrland, Software Engineer, Microsoft Edge
– Jerry Smith, Senior Program Manager, Microsoft Edge