Deploying DRM to scale includes analyzing how and where you can use persistent licensing versus non-persistent licensing. This blog provides a strategy to lower your overall DRM licensing costs by tapping into persistent licensing.
One of the frequently asked questions our customers ask:
- How may I cut the cost of a license per playback?
- How may I lower the playback startup time?
- I have a subscription model and I want to allow my end-users to watch all the channels with a single license
Let me try to answer these questions in the following blog by introducing, or refreshing your memory on a topic of a persistent and non-persistent license. And I will also mention how one may use the KeyOS WebPlay to add persistent licenses support to their web solutions.
Understanding a Session
As you know to playback the DRM protected asset, you need a license. On every playback, the playback client determines if the asset is DRM protected and if a license is needed and makes a request to the license API to get one.
It is important to understand what does “every playback” means.
Content Decryption Module, Encrypted Media Extensions, Web…
If we talk about the DRM compatible players that utilize the Browser’s Content Decryption Module (CDM) and the Encrypted Media Extensions (EME) API (usually web players), then the “every playback” means a new playback session.
It means that when the playback starts, the browser creates a context for message exchange with the CDM as a result of which key(s) are made available to the CDM to decrypt the content. See Figure 1 which demonstrates the process.
Figure 1. Requesting a license within the session’s context
Please, note that Figure 1 is a very simplified version of the original diagram available in the EME specification.
When the end-user hits the play button:
- The playback client sends the message to the browser’s media stack to start the playback.
- The media stack explores the content, notices that it is encrypted and signals back to the playback client.
- The playback client, besides other things, asks the browser’s media stack to create the session within which it will provide the CDM the license with keys required to decrypt the content.
- The media stack creates the session and asks the CDM to create a license request.
- The CDM creates the request which is then returned to the media stack and further to the playback client.
- The playback client makes a license request and returns the license to the media stack which later passes the license to the CDM. As you can see, this all happens within the context of a previously created session.
- The browser’s media stack may now request the CDM to decrypt encrypted content to start the playback.
So, the session was created and the playback started. If end-user will pause the playback or will seek through the content, or if the playback client will start switching between different bitrates (consider all of the bitrates are encrypted with the same key), it will all happen within the session that was created and no new license request will be made to the DRM provider.
If, on the other hand, the session is interrupted i.e. the playback is stopped (not paused), the browser is closed, the browser’s tab is closed, then to resume/start the playback a new license will be required and it will be requested by the playback client in the context of a newly created session.
The idea of the “every playback” concept doesn’t change if we move to a native world where players are closely integrated with the OS either directly, or with help of different SDKs like PlayReady Porting Kit, Widevine CDM.
Before the playback start, the playback client will ask the system about whether a license is available in a local DRM store. If there is no license available, a new one will be requested and will be valid within the session context during which end users may pause or seek as well as playback clients may switch between bitrates. But, as soon as you interrupt the session by stopping the playback you are looking to a new license request once you hit play again.
Session and license types
It would be great if we could somehow save the session’s context to preserve the key, or store the license somehow in a local license store in case of a native approach, wouldn’t it?
And there is actually. Licenses can be persistent and non-persistent.
Non-persistent licenses are one-time licenses which are not stored anywhere on a device. They are valid once and then they are gone.
Persistent licenses on the other hand can be stored in a local license store on a device and playback clients may re-use the license over and over again until it is removed or becomes invalid (expired).
If you will be reading the EME Specification, you will see that persistent and non-persistent licenses correlate with session types. Non-persistent license corresponds to a “temporary” session. It is a type of session that is not persisted. Persistent license corresponds to a “persistent-license” session type that can be persisted and re-used.
What defines a persistent license
A persistent license is a license with either the expiration policies set, or with the persistency flag set, or both.
When you request a license from the KeyOS MultiKey API, you may define expiration policies using the Authentication XML. You can set the expiration date, the expiration after the first play, license duration, etc. The license that will be returned to you will be persistent. What you can also do is you can request a license with the persistency flag set true and without any expiration policies. In this case, the license will be persistent and will never expire.
I must have persistent licenses in place?
Sure, but, before you decide on that, please, make sure that persistent licenses suit you.
Indeed, those save you money and allow for offline playback, etc. But those also take away some of your business model’s flexibility and those are not supported everywhere.
The main thing to remember about the persistent license is that you can’t take it away, you can’t revoke it.
If you use a non-persistent license daily, you are in full control over every end-user’s playback. Every time the end-user hits play, you can alter rights of a license, decide whether to issue a license or no, etc.
Now, let’s say you issue a persistent license for a week. Your end-user is now stuck with rights you have set in a license for a week and you can’t alter those. You may want to cut access to the content your customer bought and downloaded, but you can’t revoke the license. Or you may want to add or remove some of the output protection settings from a license, but, again, you can’t do that, not for another week for that specific customer.
When you want ready to calculate how much you can shave off of your monthly bill, you need to take into consideration that persistent license is not supported on every platform, device, and browser out there.
We have made some tests based on which we found out the following (more info here - https://www.buydrm.com/keyos-compatibility-matrix):
- Native players like AVPlayer and ExoPlayer and solutions that are based on PlayReady Porting Kit, or Widevine CDM do support persistency. In other words, you can request persistent FairPlay, Widevine, and PlayReady licenses on devices running Android and iOS and those will be stored in a local license store for later use.
- Web players suffer from the lack of support of persistent licenses/sessions on some platforms and in some browsers:
- Chrome supports persistency on PC, Mac, and Android with Widevine
- Opera allows support on PC and Mac with Widevine
- IE11 and Edge legacy allow persistent PlayReady licenses on PC
- Edge Chromium support persistent PlayReady licenses on PC and Widevine on Mac and Android
- Safari lacks persistency support on all platforms
- FireFox, although packing the Widevine CDM, still failed to support persistent licenses on PC, Mac, or Android. Probably due to a CMD/EME implementation specifics.
- SBS, Smart TVs, etc. – if you want to find out more about persistency support on these platforms, you need to contact the vendor directly for more accurate information.
When I say that the platform doesn’t support persistent license it means that if you will try to deliver one, it will be treated as a non-persistent one.
Note: It is different from web-players that require that you set a specific session type to use persistent license. If you set up your web-player to work with the “persistent-license” session type and the browser doesn’t support it, you will get an error.
Noted! I want to try persistent licenses on different platforms
We have products to help you do that.
As you may know, we provide KeyOS MultiPlay SDK for Android and iOS devices that support persistent licenses on devices and even allow for offline scenarios (https://www.buydrm.com/multiplay).
What we also have is the KeyOS WebPlay, our HTML5 web player, which recently got an update and now supports persistent licenses in browsers that support it.
With a very simple setup that involves you defining the session type, you may create a player that will either work with persistent licenses or with non-persistent ones.
Setting the “persistent-license” session type and requesting a persistent license will instruct the KeyOS WebPlay to save the session context (and keys within it) in a local store bound to your content’s Key ID and re-use it later.
What is important to note is that the session is bound to the Key ID. This means that if you have assets encrypted with the same Key ID (you have packaged your assets as a group) and you open any asset from the group, the player will re-use the session and won’t make another license request. You can support use cases like multiple channels within one subscription that require a single license to open. Or series within the season that require a single license to open all the series.
The KeyOS WebPlay supports persistency in the browser where it is supported. Read more about it in this article, or check the compatibility matrix to find out more (https://www.buydrm.com/keyos-compatibility-matrix - License Persistence).
Please, feel free to contact us in case of any questions, we will be glad to help.
See you next time.