High viewership of live Widevine streams with inserted advertising blocks can cause so many extra license requests that they overload the license server. This article describes some practical approaches for avoiding these license request floods.This article describes:

• The difference between Widevine streaming and offline license sessions
• How Widevine license requests work with ad insertion
• Approaches for reducing the number of license requests
• Example: Reducing license requests using Media3 ExoPlayer
• Example: Reducing license requests using Shaka Player

Widevine DRM Session Types

Widevine DRM has two license types for DRM sessions:

• Streaming; equivalent to the Encrypted Media Extensions (EME) temporary type
• Offline; equivalent to the EME persistent type

Streaming License Session

Also known as a temporary session. The streaming session type is used for real-time (live) streaming playback.

The streaming session type is temporary. The streaming license for the session is valid for the duration specified in the license or until the session is closed.

Offline License Session

Also known as a persistent session. An offline session allows users to download content and watch it later without an internet connection. Offline sessions can also be used for live streaming.

The license data for an offline session is securely stored on the device with a unique identifier in persistent storage. The session Id is frequently used as a unique identifier. Later, the player can use the stored session Id (unique identifier) to restore the session and play the content without issuing a new license request to the license server.

To get an offline license for the content, the content must be entitled in the Key Management System (KMS) with a policy that allows persistent usage. Otherwise, the KMS will deny the license request for an offline license.

Widevine Content Decryption Module (CDM)

The Widevine Content Decryption Module (CDM) is responsible for:

• Preparing the license request based on the license type specified by the player for the session
• Processing the received license response according to the license type specified
• If the license type is streaming, storing the license data in temporary storage until the content key expires or the session is closed
• If the license type is offline, storing the license data securely in the persistent storage and providing the unique persistent license identifier to the player

Player Using a Streaming License Type

For a streaming session type the player performs the following steps:

• The player opens the DRM session with the CDM to set the license with ‘streaming’ session.
• The player gets the successful temporary session identifier for playing the encrypted contents.
• The player closes the session after use. At this moment the license is removed from the CDM.
• If the time surpasses the license validity period for the content keys used, the license expires and the session becomes invalid. In this case, the player must request a new license and play the content using a new session.

Player Using an Offline License Type

For an offline session type, the player must store the license in the device regardless of whether the content is going to be played or not.

To get and store the license, the player performs the following steps:

• The player opens the DRM session with the CDM to specify an offline session before requesting the offline license from license server.
• The player successfully obtains the offline license response from the license server. Note that both the device and content must be enabled with an offline policy.
• The player provides the license response to the CDM. The CDM stores the license data in the secure persistent storage and returns the unique persistent identifier (session Id) for playing the encrypted content.
• The player stores the unique identifier (session Id) provided by the CDM, the key ID, and PSSH metadata for the session with specific media identification such as content ID or manifest URL in the application storage.
• Additional rules might be delivered to the player such as license session duration or validity. These should be stored in the application storage.
• After use, the player closes the persistent session.

To play back content, the player performs the following steps:

• The player gets the key ID(s) and PSSH for the playing content and checks whether there is any non-expired persistent session identifier associated with same key ID(s) and the PSSH (and/or content ID/manifest URL) in the application storage.
• If the player does not find any matching persistent session, it opens a new offline session to get the license data from the license server and store the license data with the CDM as described above.
• If the player finds a matching persistent session, but it is expired (not valid), then the player must remove the persistent session identifier together with the Key ID and PSSH metadata and all the other metadata in the application storage. After that, the player can open a new offline session to get the license data from the license server and store the license data with CDM.
• If the player finds a valid matching persistent session identifier, the player opens the DRM session with the CDM using the persistent session identifier to restore the license data for the offline session.
• The player gets the successful persistent session identifier for playing the encrypted content.
• After use, the player closes the persistent session.

Widevine License Requests Handling

Ad Insertion and DRM

Most streaming ad insertion implementations introduce ads after the streams have been encrypted. This allows flexibility for the advertising service to place user targeted ads without integrating with complex areas of the video processing pipeline. The video player processes part of the encrypted stream, then plays the clear ad content, and after the advertising block is completed, plays encrypted content again. Most of the time the encryption key for the stream has not changed, as shown in the diagram below

With live streaming, in most cases the player will use the streaming (temporary) license type for the live playback. When the player reaches the time to play the ad (1 in the diagram above) the session is closed and the ad is played in the clear. When the ad block completes (2 in the diagram above), the player opens a new DRM session and requests a new license. This follows the process described in the section "Player Using a Streaming License Type" .

Reducing License Requests in Ad Insertion

When ad insertion blocks occur in streams with high viewership or in multiple live channels simultaneously, they can cause a flood of DRM license requests and an overload of the DRM license server.

These license requests floods can be avoided with one of the following approaches:

• Using the streaming sessions:

The temporary session is kept open instead of closing it with the underlying CDM, even while the player is not using it. Keeping the current sessions open until the license expiry and re-using the sessions when needed avoids new license requests to the license server.

• Using the offline session:

This approach effectively treats a streaming session as an offline session. The player gets an offline license from the license server for the content and stores the license in persistent storage with the CDM. For future playbacks, instead of requesting the new license with new sessions, the player can restore the offline license to play the content.

Comparison of Approaches

Both approaches are considered secure, since CDM manages the license data securely for both persistent and temporary sessions.

Practical Implementations

Android Media3 ExoPlayer DRM

In the Android Media3 ExoPlayer DRM, either approach can be used to avoid license floods.

Key rotation

To play streams with rotating keys, pass True to MediaItem.DrmConfiguration.Builder.setMultiSession when building the media item. This is required for the live streams, which have the key rotation applied.

Using a Persistent Session

In the default implementation of Media3 version 1.5.0, the persistent (offline) session approach requires downloading the content together with the offline license. The persistent session is supported only for VOD content, not for live content.

There is also a limitation in the persistent session in Media3, that only one offline key set can be specified per playback. As a result, offline playback of multi-key content is currently supported only when the license server is configured to provide all the keys in single license response. If the license server provides only the current key per license request, then this persistent session will not work in the default implementation.

Using a Temporary Session

In Media 3 version 1.5.0, the Media3 exoplayer DRM session management has been implemented in three source files:

• DefaultDrmSessionManagerProvider.java
• DefaultDrmSessionManager.java
• DefaultDrmSession.java

DefaultDrmSessionManagerProvider class has the method get(MediaItem) to return DrmSessionManager instance, for the provided mediaItem, which contains the DRM configurations (MediaItem.DrmConfiguration).

DefaultDrmSessionManager.Builder class allows to configure and build the DefaultDrmSessionManager for requested DRM configurations in the DefaultDrmSessionManagerProvider. The method setSessionKeepaliveMs in the builder allows the Session Manger instance to keep the DRM session instances alive for the specified duration, even if the sessions are not actively used by the player. The default timeout is set to 5 minutes in DEFAULT_SESSION_KEEPALIVE_MS in DefaultDrmSessionManager.java. The default timeout is sufficient for most use cases.

If the timeout needs to be changed:

1. The default for DEFAULT_SESSION_KEEPALIVE_MS can be changed directly in DefaultDrmSessionManager.java source file.
2. DefaultDrmSessionManagerProvider.java source can be changed to call the setSessionKeepaliveMs method with the required timeout during the DefaultDrmSessionManager.Builder instance creation in DefaultDrmSessionManagerProvider.java, as shown below:

  DefaultDrmSessionManager.Builder drmSessionManagerBuilder =
    new DefaultDrmSessionManager.Builder()
      .setUuidAndExoMediaDrmProvider(drmConfiguration.scheme, FrameworkMediaDrm.DEFAULT_PROVIDER)
      .setMultiSession(drmConfiguration.multiSession)
      .setPlayClearSamplesWithoutKeys(drmConfiguration.playClearContentWithoutKey)
     .setUseDrmSessionsForClearContent(Ints.toArray(drmConfiguration.forcedSessionTrackTypes))
      . setSessionKeepaliveMs(sessionTimeoutInMs);

3. The custom Session Manager Provider can be implemented to build the Session Manager configured with setSessionKeepaliveMs API for more fine-grained control of the DrmSessionManager, and the sessions associated with manager instance. One of the customizations could be doing the same as option 2 mentioned above, to extend the session alive timeout. The custom session manager provider instance is then set in the setDrmSessionManagerProvider method during the creation of Media Source Factory instance.

The default session manager (DefaultDrmSessionManager.java) implementation keeps track of all the active sessions presently used by the player in the field sessions and the keep alive sessions in field keepaliveSessions (which are not active) in the session manager instance created for mediaItem.

The default session manager tracks all the sessions with reference count usage. The default session manager automatically tags the sessions as keep alive sessions when the player does not use the session at all. The session’s keepalive timer starts immediately, based on the keepalive timeout configured in the session manager. If the player requests the license again with same DrmInitData (the same key id and PSSH), the session manager removes the session from the keepalive sessions list by making the session active and cancels the timer. If the keepalive timer is expired, then the keep alive session is closed to release all the resources with CDM and the keep alive session is removed from the keep alive session list.

The session manager also closes keep alive sessions automatically when there are any resource constraints causing the failure of new session creations, to free up the resources. When the keep alive sessions are already closed or there is no session to re-use for the requested DrmInitData, then the session manager creates a new session by making a new license request to CDM.If the session manager instance is released by the player, then all the sessions created by the session manager instance are also closed automatically for both active and keepalive sessions.

Shaka Player

The Shaka Player implementation (v4.13.2) does not provide any support to keep the sessions alive as in the ExoPlayer DRM implementation. The only option for browser based is to use the persistent sessions to avoid the license request.

📘

NOTE

The persistent license is not recommended for browsers, as Google intends to remove license persistence capability from the desktop browser CDM in 2025.

The Shaka Player documentation explains how to use the persistent session.

First Time Playback

Configure Shaka to start DRM sessions with the persistent-license type instead of the temporary one:

player.configure({
 drm: {
  advanced: {
   'com.widevine.alpha': {
    'sessionType': 'persistent-license'
   }
  }
 }
});

Retrieving and Storing Session Ids

When the playback starts, you can retrieve the sessions metadata and store them in local storage, to uniquely identify the content with the associated sessions information:

function onDrmSessionUpdate(event) {
 const activeDrmSessions = $scope.player.getActiveSessionsMetadata();
 if(activeDrmSessions != undefined) {
  const persistentDrmSessions = activeDrmSessions.filter(
  ({ sessionType }) => sessionType === 'persistent-license');
  if(persistentDrmSessions != undefined) {
  //Store with persistent sessions information with unique Key to retrieve it later
  localStorage.setItem('ContentID', JSON.stringify(persistentDrmSessions));
  }
 }
}

Play with Stored License

To play with stored license, the player needs to configure for persistent playback with retrieved session information:

function configurePersistencePlayback() {
  var persistentDrmSessions = JSON.parse(localStorage.getItem('ContentID'));
  if (persistentDrmSessions != undefined){
  player.configure({
  drm: {
    persistentSessionOnlinePlayback: true,
    persistentSessionsMetadata: persistentDrmSessions,
   }
  });
  }else {
   //Continue with the online 'temporary' or new 'persistent' configuration
  }
}

The persistentSessionsMetadata will contain the information sessionId, initData and initDataType, to restore the license information from secure persistent storage by the CDM.