CODEWITHSUNDEEP
javascriptinternet-explorersafarihtml5-videodrm
kadina
kadina

Reputation: 5382

Encrypted event equivalent for DRM content in safari and IE browsers

We are using Encrypted event in Chrome browser to know the video content is DRM protected and when our player receives the event, we start creating session and request DRM key from server. But this event is not supported in Safari and IE browsers. Can any one please suggest which event we need to listen for other browsers like Safari to know the video is stopped playing because it is DRM protected?

Upvotes: 0

Views: 2544

Answers (1)

Mick
Mick

Reputation: 25491

Firstly, it is worth saying that all the latest versions of the main browsers support Encrypted Media Extensions (EME) for playing back encrypted streamed video now. If you are using one of the common 3rd party Javascript players, e.g. BitMovin or JWPlayer, then playback of encrypted content across browsers should 'just work'.

EME is an extension mechanism that allows the browser build on the HTML5 video capability to detect encrypted content, request the key and using the key decrypt and playback securely the encrypted content.

EME itself is an API that defines the interacting between the application, browser, media player and CDM (Content Decryption Model). Its is specified by W3.org and the following diagram form the latest spec gives a good feel for the flow:

enter image description here

You can see that the browser detects that the media is encrypted when it receives it from the CDN (not CDM...). The browser will create an 'encrypted' event and send it back to your application (or to whatever has registered to listen to video events).

There are two ways, AFAIAW, to see the encryption event - you can register a listener like this (see this example - https://www.html5rocks.com/en/tutorials/eme/basics/ ):

var video = document.querySelector('video');
video.addEventListener('encrypted', handleEncrypted, false);

Or you can include it as an attribute (see the example in the EME spec linked above):

<video autoplay onencrypted='handleInitData(event)'></video>

However, as you say the event is not supported across all browsers at the moment - the latest support is here: https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/onencrypted#Browser_compatibility

One thing you can do while this support is not there is to look at the video metadata itself to identify whether the video is encrypted.

For an MPEG DASH fragmented MP4 video, the information will be in one or both of the following places:

  • in the manifest file (the mpd file).
  • in a header in the mp4 stream itself - the PSSH 'atom' or box.

Most DASH protected files will have the information in the manifest and it should be easy to check - it will look like this:

</AdaptationSet>
        <AdaptationSet segmentAlignment="true" group="1" maxWidth="852" maxHeight="480" maxFrameRate="24" par="16:9" lang="und">
            <ContentProtection schemeIdUri="urn:mpeg:dash:mp4protection:2011" value="cenc" cenc:default_KID="80399bf5-8a21-4014-8053-e27e748e98c0" />
            <ContentProtection value="ClearKey1.0" schemeIdUri="urn:uuid:e2719d58-a985-b3c9-781a-b030af78d30e">
                <clearkey:Laurl Lic_type="EME-1.0">https://drm-clearkey-testvectors.axtest.net/AcquireLicense</clearkey:Laurl>
            </ContentProtection>

This example uses clearKey, but the important bit from your point of view is the existence of the 'ContentProtection' attribute in the manifest.

Similarly, if your video is being streamed with HLS, the m3u8 playlist, which is the HLS equivalent of the manifest, will have an indicator that the media is encrypted which you can check. This is the 'EXT-X-KEY' flag:

#EXT-X-KEY:METHOD=AES-128,URI="http://AKeyServer/sceret.key"

The way the video players stream the video is using the HTML5 Media Source Extensions mechanism (https://www.w3.org/TR/media-source/). This allows you set the source of a video to be a local object rather than a video URL. The players are able to look at the manifest to get the URL for the video stream they want to play and then download that video chunk by chunking, appending it to this local 'src' object as they go. The browser video player takes the video from this object as if it were a regular video file source.

There is a very widely shared example here which helps demonstrate the approach: https://developers.google.com/web/updates/2011/11/Stream-video-using-the-MediaSource-API

So the Javascript players actually only need to be told the Url for the manifest file itself - each will have different ways to get this, but you can see how Shakaplayer does it by looking at the source on Github (https://github.com/google/shaka-player) and search for the term 'manifestInput' (correct at the time of writing) - from here you can trace how Shakaplayer accepts this input, parses the manifest file and then plays the video streams.

Upvotes: 1

Related Questions