Testing DRM Protected Video Playback on Real Devices Using Player SDKs

If you have a streaming application, you rightfully want to protect your licensed and original content from illegal activities.

You don’t want people to record any content and share it or distribute it. To prevent this, you might be adding additional DRM protection methods into the SDKs or playback logic, which is responsible for streaming the content from the CDN server to the device.

What we have observed is that many of the big streaming companies are not building their own Playback handler, so they are using SDKs (typically called Player SDK) to protect their content.

These Player SDKs often have built in protections, and usually do similar security detection to what a Secure SDK would do, such as detecting:

Third party Player SDKs do not expose how they protect content, which makes it difficult to run these applications in cloud based devices or on devices where screen recording or screen grabbing is enabled. All these tools are required to test and validate these applications in a remote environment. There are many more, but a few examples of these SDKs are:

When tests using these Player SDKs are run on Sauce Labs, there could be some issues including a black or blurred screen when launching the app or opening a screen with DRM protected content. This is good news since your Player SDK is protecting the content properly! But you still need to test that the video stream works.

On Android devices, you can enable the Bypass Screenshot capability from your app settings if your DRM protection in the Player SDK is using the FLAG_SECURE method.

If that doesn’t work, there is a chance that the Player SDK used for streaming is using additional hardening that is more strictly secured and/or using reflections.

For both Android and iOS, you can create a new build target/gradle target in order to lower the security in your Player SDK. This is usually an additional flag to pass to the SDK, or you can use the DEBUG version of the SDK.

For functional tests, we recommend creating a separate QA/TEST build target, with a lower security restriction in the Player SDK (disable screenshot and recording protection). 

This is how you can create a new build target in iOS/iPadOS in Xcode. 

And this is how you can configure your build variants and product flavors on Android.

The player SDK might detect the following:

In this case, an error message would appear on the screen when the app is launched, or you might be unable to view protected content.

The solution is the same as above: use a separate build target/variant with lowered PlayerSDK restrictions. Then upload these applications to Sauce.

Testing your content and the right workflow in a device cloud platform allows for efficient and thorough testing across a wide range of devices and platforms. This reduces the risk of bugs or issues that may arise on specific device and OS combinations; and it ensures that these issues are not going to appear on production. 

You will need to test DRM protection only once–that it works efficiently–so you can focus the rest of your testing efforts at the right business logic validation. You can always test your SDK with lower level component or unit tests, to ensure the DRM protection is enabled before production release.

This helps to ensure that your application is streaming the correct content, with the correct audio and video quality your business requires. This can save time and resources for you, as your teams no longer need to purchase and maintain a wide range of physical devices.