DASH stream playback with NAGRA CONNECT

To test this feature and view the connect-dash example code, please see the Android SDK 5 Example Code Quick Start guide.

Like other protected content, the CONNECT Player makes use of an OTVCommonMediaDrmCallback-derived class - OTVConnectMediaDrmCallback. Unlike HLS+CONNECT, there is no use of the OTVConnectManager class; the implementation is more like DASH plus Widevine.

The CONNECT Player supports the CENC encryption sampling method (including support for multiple encrypted sub-samples); pattern encryption is not supported. Support for CBCS/CMAF with CONNECT PRM is not guaranteed and depends on the underlying SoC.

PRM signalisation can be provided as either a <cenc:pssh > tag or <prm:PRMSignalization> tag inside the <ContentProtection> tag (in the stream's manifest .mpd) or inside the header of the downloaded segment. Signalisation data in the manifest will override data in the segment.

Enabling playback of CONNECT-encrypted DASH streams comprises the following steps:

Initialisation and configuration of the callback class for working with the CONNECT-enabled licence server, including setting the Operator Vault.
Configuration of the callback object with stream-specific parameters.
Setting player view with callback object and stream path.

Unlike CONNECT plus HLS, there is no need for the OTVConnectManager and no specific actions for provisioning.

OTVConnectMediaDrmCallback

The SDK provides the OTVConnectMediaDrmCallback as the default implementation of the OTVMediaDrmCallback interface, which handles communication with the provisioning and licence servers and is used in the example code. This is the same class used for CONNECT+HLS.

Rather than directly implementing the OTVMediaDrmCallback interface, OTVConnectMediaDrmCallback implements the abstract OTVCommonMediaDrmCallback class, which has a single constructor with the parameter defaultLicenseUrl.

Some licence servers expect extra information from the application. This information is a blob of data in a specific data field within the key request challenge data from the MediaDRM plugin and is sent to the licence server. You can configure the MediaDRM plugin library to add that extra data by setting an option in the OTVConnectMediaDrmCallback class instance. For example, configuring the clientData and/or protectedClientData fields with application data adds this data to key requests' challenge data as third-party applicationClearData and applicationProtectedData data fields respectively. For more information, refer to your licence server documentation.

Initialisation and configuration

The OTVConnectMediaDrmCallback is similar to callback classes provided in the CONNECT Player SDK; please note:

Configuration of the OTVConnectMediaDrmCallback requires one additional step - setting up the Operator Vault data.
This is done by reading the opvault.json file as a binary stream and passing the byte array as a "nagraOpVault" DRM property connectDrmCallback.setDrmPropertyByteArray("nagraOpVault", opVault);
Provisioning is only required once and will take place (if not previously provisioned) when the Android system's executeProvisionRequest() is called.

Provisioning

The OTVConnectMediaDrmCallback class, provided in the SDK, has built-in handling of provisioning requests by implementing:

JAVA

@Override
public byte[] executeProvisionRequest(UUID uuid, ExoMediaDrm.ProvisionRequest request) throws MediaDrmCallbackException

Licence request

The OTVConnectMediaDrmCallback class, provided in the SDK, has built-in handling of license requests by implementing:

JAVA

@Override
public byte[] executeKeyRequest(UUID uuid, ExoMediaDrm.KeyRequest request) throws MediaDrmCallbackException

Setting stream-specific playback parameters

Stream-specific parameters typically comprise stream tokens (configured in the callback) and other parameters set in the callback's setKeyRequestProperty() , setKeyRequestOption() and setDrmPropertyByteArray().

Setting player view with callback object and stream path

Once all parameters are configured in the callback, the callback reference is passed to the player (OTVVideoView) instance using OTVVVideoView.setMediaDrmCallback() and the stream's path can be set to begin playback.

Multi-session mode

The callback must be configured to multi-session mode when more than one key is required to play a stream, such as:

Key-per-track - for example, when video and audio are encrypted with different keys or when the HD adaptation set requires a different key from the SD adaptation set.
Key-rotation - where keys change over time
Temporal pre-delivery - when multiple keys are delivered ahead of key rotation to save key requests.

Internally, the player starts a DRM session whenever a key is required. Playback will stop if more than one key is needed in a single-session mode.

By default, multi-session mode is enabled. To set the callback for multi-session mode, the following should be called (before starting playback):

JAVA

callback.setMultiSession(true);

Post-delivery renewal

In a typical scenario, especially on handheld devices, a licence is fetched and used for the decryption key when a user plays an encrypted DASH content item. The licence is limited by an expiry time that provides the user ample time (for example, 24 or 48 hours) to use and watch the content before the licence expires. For set-top boxes, however, content playback could span several days beyond the original expiry time. The Example code for DASH stream playback with licence extension option page illustrates a mechanism for the application to be aware of the expiry time and to extend the licence.

Extending the CONNECT licence expiry time requires the CONNECT MediaDrm plugin version 3.2.0 or above. The details of the content token set the extension of licence expiry. Setting expiry time can be done by either providing a duration value (in seconds) or by specifying an end time (UTC date).

When setting a floating duration, the extension occurs only after the current licence has expired, and the app will not be notified with a meaningful expiry time in the onExpirationUpdate event.
When setting an end time, the extension occurs immediately, and the app will be notified within the onExpirationUpdate event with time (in ms) since Unix epoch.