This topic covers how to protect your videos in apps with the Video Cloud Digital Rights Management feature (DRM), using Google Widevine.
Widevine is available in two varieties:
- Widevine Modular - The newer form of Widevine works for videos in MPEG-DASH format. It is recommended for playback in broswers for the Brightcove Player and in Android apps using the Brightcove Player SDK for Android.
- Widevine Classic - The older form of Widevine that works for special .wvm video archives. Widevine Classis is deprecated, and you should migrate your content to Widevine Modular.
For iOS apps built using the Brightcove Player SDK for iOS, you should use FairPlay if you require DRM.
Creating Widevine DRM packages
DRM packages are created during the video ingestion process. Packages are specified in custom ingest profiles. For information on creating Widevine packages, see Content Security (DRM and HLSe).
Videos for Andriod apps - Widevine Modular
Video Cloud DRM offers the option of using Google Widevine to secure your content at its origin. This means that Video Cloud manages the packaging of each individual video as a protected asset along with its metadata.
How you should specify packages for Widevine Modular depends on the nature of the content:
- Single file - Best when all of the content has the same display resolution, frame rate, and encoding profile. For example, a smart TV manufacturer who is delivering content to televisions. When multiple renditions with different resolutions are present in the same package, playback is fine until certain Android devices attempt to switch to a different rendition. We have seen cases where the display becomes garbled and the application crashes.
- Set of files - Best when the content has different display resolution, frame rates, and encoding profiles. For example, when delivering content to Android devices.
For example, let's say a publisher's transcoding options contain 6 renditions, 2 with a resolution of 400x300, 3 with 780x400, and one with a resolution of 1280x700. The account is configured to use Widevine. After the upload, the publisher would have 3 .wvm files in that title. One .wvm containing the 2 400x300 renditions, one containing the three 780x400 renditions, and one containing the single 1280x700 rendition. This is the default behavior for Widevine upload, however, there is an account setting which, when enabled, will cause all renditions, regardless of resolution, to be packaged into one .wvm file.
Note: Widevine renditions cannot be previewed or played inside Video Cloud Studio.
Widevine will only use the MPEG-DASH renditions and ignore the HLS renditions. Note that the Widevine client is responsible for handling the rendition switching.
When the client tries to view a video that has been encrypted using Widevine, the Widevine client, which is part of the player, will make a call out to a license proxy server which will determine if it can get a license for the piece of content. The license is delivered from the license server (which is controlled by Google) in a secure fashion down to the client which uses it to decrypt the video.
Signing up for DRM
This feature requires an additional fee. Video Cloud offers other options for protecting your content across devices. See Content Protection and Digital Rights Management for more information. Contact your Account Manager about bundling DRM protection so that you can secure your content wherever it plays.
What happens after Widevine DRM implementation
After Widevine DRM implementation, Brightcove handles all licensing and packaging of your video assets, each with a unique encryption key. The first time a DRM-packaged video plays, the Video Cloud player silently takes a few seconds to download the required decryption key for that video.
Video Cloud packages and encrypts all renditions of newly uploaded videos as the first priority. Any videos uploaded before Widevine DRM implementation will continue to be available for play in an unencrypted state until the DRM process encrypts it.
Technical FAQ
What is the key handling sequence in the device?
A key request is initiated with the Widevine client software, and made through the device's native HTTP libraries. This request is sent via SSL to Brightcove's license proxy servers, where we sign it and forward it to Widevine's license servers. This provides Brightcove a mechanism to inject additional policy requirements, and to verify that playback is appropriate in the context of Brightcove's business rules. Widevine returns an encrypted license response (presumably with a device-specific key), which Brightcove passes, unmodified, and still via SSL, back to the requesting device. The key is decrypted and disposed in the context of Widevine's client software.
Are the encryption keys randomly generated or a set sequence?
Keys are generated by Widevine, Brightcove assumes they are randomly generated.
Are the encryption keys different for each asset?
Keys are generated by Widevine. Brightcove believes they are unique for each asset.
How do you make sure that the encryption keys are not re-used?
Keys are generated and maintained by Widevine. Brightcove assumes they are not re-used.