Limiting Concurrent Streams per Viewer

Introduction

With concurrent stream limits, you define the number of video streams that a specific user can watch at any given time. Limiting concurrent streams per user discourages viewers from sharing their credentials with friends who don’t have accounts.

When the maximum number of concurrent streams is reached, and the viewer, or someone with their account credentials, tries to open an additional stream, either the oldest session is stopped or the newest request is blocked. You control this behavior.

This feature hooks into the DRM workflow so it is secure and can be used with minimal integration.

If you are new to this feature, see the Overview: Brightcove Playback Restrictions document.

Account setup

Contact your Customer Success Manager to have your account enabled for stream concurrency.

Implementation

For this feature, the content needs to be encrypted DRM. To implement, follow these steps:

1. Determine the claims values:

   • The climit claim indicates how many watchers or streams can play at the same time.
   • The cbeh claim defines how to block the concurrency. When the stream limit is reached, you can either block a new viewer (meaning a different IP address and device) or block a new stream request (session).
     • cbeh value BLOCK_NEW_USER - Block new viewers
     • cbeh value BLOCK_NEW - Block new streams
2. Create a JSON Web Tokent (JWT) with claims associated with your desired concurrent stream limits. For details see the Creating a JSON Web Token (JWT) document.
3. Configure your player to use playback restrictions and pass the JSON Web Token (JWT) when retrieving your video content. For details, see the Configure your player section of the Implementing Playback Rights Management Service document.

Renewal interval

To ensure that concurrent stream limit is enforced, a DRM license renewal request is sent during playback based on a defined renewal interval. At setup time, you are required to define this renewal interval.

Mid-stream playback authorization requests need to specify a concurrency limit in the JWT token along with a public key id.

Today each renewal request counts as an additional license that would go towards the number of your purchased licenses. This should be taken into account when you are deciding on an interval.

Understanding behavior

With this feature, you can choose the behavior for blocking streams.

Block oldest stream

Brightcove supports limiting playback streams for DRM-protected content. When a new renewal request is processed, the oldest session is stopped. This allows new user requests to be given access, while blocking the oldest requests which may no longer be valid, displaying a message about network or device failure.

This is the default behavior.

User activity by column:

1. Ben, Jason and Sarah begin watching a movie.
2. Jamie decides to also start watching, causing Ben's upcoming renewal request to be denied.
3. Ben restarts the movie, now causing Jason's renewal request to fail.
4. Jason starts watching another movie some time later, causing Sarah's movie to stop.

Block new users

You can also block a new viewer/user (meaning a different IP address and device) when the maximum number of concurrent streams is reached. This limits the number of current unique users, but allows each user to have multiple requests.

To enable this behavior, you need to set the cbeh claim in your JSON Web Token (JWT) as follows:

"cbeh": "BLOCK_NEW_USER"

Here is an example:

User activity by column:

1. Ben, Jason and Sarah begin watching a movie.
2. Jamie tries to start watching, but her request is blocked because of the maximum limit.
3. Jason stops watching, allowing another viewer to start watching. Jamie starts watching a movie.

Block new streams

Alternatively, you can block a new stream request (session) when the maximum number of concurrent streams is reached. This allows all of the current users to keep watching, while displaying a message to any new user requests.

To enable this behavior, you need to set the cbeh claim in your JSON Web Token (JWT) as follows:

"cbeh": "BLOCK_NEW"

Here is an example:

User activity by column:

1. Jason, Jamie, and Sarah begin watching a movie.
2. Jason tries to start watching a second stream from his device, but his request is blocked because of the maximum limit.
3. Jamie stops watching, allowing another session request to start watching. Jason starts watching a second stream.

PlayReady

PlayReady does not support mid-stream license checks.

Current Brightcove Player

If you are using Brightcove Player v6.48.x or newer, than the player sets the preferred order for Edge browsers to use Widevine instead of PlayReady. So, PlayReady should not be an issue.

You can find the fix for EPA DRM source selection in Chromium Edge browsers in the Brightcove Player Release Notes.

Older versions

Older versions of Brightcove Player use the Chromium Edge browser default of PlayReady first. In this case, you have to perform the mid-stream license checks manually.

To implement a manual license renewal in your players, see Microsoft's Concurrency Limiting document.

Safari

Concurrency limit is supported in the Safari browser, but renewal requests will not be sent. This means that new sessions/streams will be blocked for longer time periods than with other browsers.

When limiting concurrent streams with DRM, casting from the Safari web browser to Airplay is not possible. Casting to Airplay is only possible from a native app using the Brightcove Native SDK for iOS.

Notes

The following notes apply to this feature:

• Manual license renewal request should be implemented in the following cases:
  • Concurrency limit in non-Brightcove players, except when protected by Widevine
  • Concurrency limit for PlayReady in all devices, except when using Brightcove Player v6.48.x or newer
• Manual license renewal should be requested at a shorter period than the defined renewal interval.