New abstract license server support and DRMToday

[greg80303]

The existing DRM license server code was much too dependent on
a select few servers that we use for testing. The HTTP method,
the response type, and the format of the response message will
all be different depending on the license server.

A new abstraction is introduced with example implementations in
the MediaPlayer.dependencies.protection.servers namespace. This
new API is called from ProtectionExtensions.requestLicense() which
replaces the previous functions that were implemented by each
KeySystem. The license request/response procedure is not really
keysystem-specific anyway, it just so happens that we were always
using the same basic license server types for each system we supported.

A new license server implementation has been added for the DRMToday
(www.drmtoday.com) DRM service from CastLabs. This is the first
licensing system integrated into dash.js that allows us to create true
CommonEncryption content with multiple "real" DRMs (using CableLabs
open source tools) and playback in an open source player. New test content
for PlayReady/Widevine has been created and added to the sources.json.

ProtectionData is no longer stored in the KeySystem objects, but in
ProtectionController and passed in to each license request call (all
ProtectionData thus far has been used solely for license requests).

The "bearerToken" field of ProtectionData has been removed since it
was only used in MS PlayReady to add HTTP request headers (which
can already be specified in ProtectionData).

[dsparacio]

@greg80303 were you able to figure out the singleton to class issue you spoke about in Berlin? Is that part of this change? Otherwise this looks really nice. I like the new classes for DRM types. 👍

[greg80303]

@AkamaiDASH No, this PR does not cover that issue. I still need to work out a separate fix for that one. I'm not a fan of the solution that we discussed in Berlin (make ManifestLoader a singleton again and return an error event if a manifest download is currently progress) because it means that anyone who uses ManifestLoader will have to implement retry logic. Stay tuned...

[ghost]

@greg80303 @AkamaiDASH Greg isn't the retry logic (on error in download) there in ManifestLoader.js? I think we discussed that we'll not create StreamController etc till your download is done. So there won't be any download in progress.

[bwidtmann]

This looks nice. Especially binding the LICENSE_REQUEST_COMPLETE event on the ProtectionExtensions rather than on the specific ProtectionModel solves some timing issues we had.

We already tried it and it works on our productive DRM workflow.

[greg80303]

@AkamaiDASH @KarishmaBagga Since this topic is not really related to this pull request, I'm going to do what I should have done in the first place, which is to create a bug for that specific problem and we'll move this conversation over there to avoid confusion.

[greg80303]

@AkamaiDASH @wilaw @KozhinM In our last call, we originally decided to hold off on merging this pull request until after the 1.4 release. However, there seems to be some interest in this change and it looks like @bwidtmann has already tested it. So, any objections to merging this before the release?

[dsparacio]

@greg80303 no objections from me. 👍 @KozhinM any objections?

[shoniko]

Sorry to go a bit off topic, but I am not 100% sure why you would say DRMToday is "the first license server that allows us to create true CommonEncryption content with multiple "real" DRMs". We at BuyDRM have had this demo for quite a while already: http://demo.keyos.com/html5/KeyOS-MultiDRM-Demo.html. The underlying stream there has not only Playready and Widevine signaling, but Marlin as well. Please feel free to use it in your tests and include it in the sources.json. In fact you can check out our other demo streams and see if there's anything else you might be interested in.

[KozhinM]

@greg80303, @AkamaiDASH, I have no objections too.

[greg80303]

@shoniko I apologize for the wording into the pull request. I have updated the text to more accurately reflect the message I am trying to communicate. This is the first multi-DRM licensing system to be integrated into dash.js (not the first to come into existence). It is important that we have this kind of support in the player to highlight the benefits of EME and CommonEncryption. Also, the DRM services supported by dash.js are all fully supported by the open-source content creation tools we have developed at CableLabs. These tools are not necessarily meant to be used in production, but to educate people on ABR, DASH, DRM, and CommonEncryption. Additionally, I am responsible for creating official test content for DASH-IF and we must have multi-DRM content that works in our player.

As you would expect, anyone who wants to create content using one of these commercial licensing services, would need to have a service agreement with the provider (as I have negotiated with DRMToday). However, since the process of retrieving licenses and the data the app must provide is very dependent on the requirements/APIs of the provider, you must have specialized support in the player. With this code change, it is easier than ever to add native support for additional licensing services in dash.js. If you would like to have support for BuyDRM integrated, we'd be happy to look at a PR.

Sorry again for the confusion.

[rincedd]

As @bwidtmann already commented, this works nicely for our DRM flow. I particularly like abstracting away DRM server specifics with the new DRM servers abstraction.