This article gives an overview of common practices for applying DRM protection to Dolby audio and video content. DRM concepts, device and platform specific limitations and technical guidelines for common DRM schemes are shared, Dolby video and Dolby audio related requirements and best practices are explained.

Table of Contents:

01	DRM Basics This section outlines DRM terminology and concepts that are mentioned in this article.
02	Common DRM Guidelines This section explains common DRM guidelines for all type of audio video content.
03	DRM Guidelines for Dolby Vision This section describes DRM guidelines and requirements for Dolby Vision video.
04	DRM Guidelines for Web Browsers on Windows PC This section focuses enabling Dolby Vision and Dolby Atmos on Windows PC platform. Browser-specific DRM requirements and limitations are explained and example configurations are given.

 

1. DRM Basics

1. What is DRM?

   Digital Rights Management (DRM) is a security framework that allows content distributors to control how content is used on each device, ensuring that both the subscriber entitlements defined by the streaming service provider are enforced and the content owner’s security requirements are met.

2. How does DRM work?

   DRM involves encrypting digital media, which can only be decrypted and played back with a specific license key provided to authorized users. Also, DRM allows service providers to set content access parameters such as access windows, device-specific access types, regional restrictions, output protection and concurrency limits.

3. Which Contents can be protected with DRM?

   DRM provides access-control tools to prevent unauthorized copying, sharing, or piracy of any digital content. Any digital media content, such as movies, TV shows or music, delivered through file-based (VOD) or live streaming formats can be protected using DRM technology.

4. What are Common DRM technologies?

   DRM technologies require integration into end devices as either hardware- or software-based solutions. Common DRM systems available in today’s consumer devices are Google Widevine, Apple FairPlay, and Microsoft PlayReady.

5. What is difference between Software-DRM vs Hardware-DRM?

   Software-based DRM protection is built into software layer of a device, either in the device's OS, playback platform or SDK. In software DRM implementations, the player application takes the decrypted/decoded content and pushes it to the device’s screen. This means that audio/video data leaves the protected environment at some stage and may be compromised by software applications that are not controlled by the DRM system.

   Hardware-based DRM protection requires devices to have a trusted execution environment (TEE) pre-built inside its hardware as a closed-system where all DRM licensing, decryption, and decoding operations occur within a chipset. Content is transmitted directly from the chipset to the device’s screen, restricting access to the data while it is in transit. This provides maximum content security as it’s much more difficult to compromise data.

2. Common DRM Guidelines

This section outlines common DRM guidelines for all type of audio video content. These guidelines should be observed for Dolby Audio and Video too.

1. Device and Platform Support

   Multimedia devices and players are shipped with different DRM support. To enable content streaming across multiple devices, the DRM capabilities of the target devices must be identified. This means you must first define the target devices, including device type, OS version, player type, etc. and then find out which DRM technologies are supported on those devices.

   Knowing which DRM systems are supported on which device and platform is not always straightforward. You can find some popular devices and their native DRM support as a guideline in below table. Note that devices and platforms are normally shipped with built-in DRM support, but there may be other methods of enabling additional DRM systems such as implementing an SDK.

     

   Windows PC	PlayReady	Widevine	FairPlay
   Edge Browser (on Windows PC)	✅ Supported	✅ Supported	✖ Not Supported
   Chrome Browser	⚠️ Win 11 Only	✅ Supported	✖ Not Supported
   Firefox Browser (on Windows PC)	⚠️ Win 11 Only	✅ Supported	✖ Not Supported

     

   Smart TVs and DMAs	PlayReady	Widevine	FairPlay
   Hisense Vidaa	✅ Supported	✅ Supported	✖ Not Supported
   LG WebOS	✅ Supported	✅ Supported	✖ Not Supported
   Android TV	✅ Supported	✅ Supported	✖ Not Supported
   Roku	✅ Supported	✖ Not Supported	✖ Not Supported
   Amazon FireTV	✅ Supported	✅ Supported	✖ Not Supported
   Apple TV	✖ Not Supported	✖ Not Supported	✅ Supported

     

   Apple Ecosystem (iOS, macOS, tvOS)	PlayReady	Widevine	FairPlay
   Native Player (AVFoundation/AVKit)	✖ Not Supported	✖ Not Supported	✅ Supported
   Safari Browser	✖ Not Supported	✖ Not Supported	✅ Supported
   Chrome Browser (on macOS)	✖ Not Supported	✅ Supported	✅ Supported
   Chrome Browser (on iOS, iPadOS)	✖ Not Supported	✅ Supported	✅ Supported

     

2. Multi-DRM

   Since DRM support of every device is different, a single content must be protected with multiple DRM systems for streaming to different type of devices and platforms. Multi-DRM allows a single piece of content to be prepared once and then played back on various devices using the DRM type supported on each device.

   Multi-DRM protected content must be packaged in accordance with Common Encryption Specification (ISO/IEC 23001-7), which defines standard encryption and key mapping methods that enable the same content file to be decrypted using different DRM and key management systems.

   The three major DRM systems whose support spans nearly the entire device ecosystem are Google Widevine, Apple FairPlay, and Microsoft PlayReady. Common approach is to use a Multi-DRM solution that incorporates these three DRM systems.

3. Multi-Key

   There are two options for handling the encryption of the content:

   • Single Key: A single key is used per content title. This single key is used to encrypt and decrypt any of audio, video renditions of the content.

   • Multi-Key: Individual keys are used for different tracks (or group of tracks) of the content based on the properties such as stream type (audio, video, or subtitles), resolution (UHD or HD), bitrate, or language. As a result, multiple keys are required to encrypt and decrypt each title.

4. Clear-Lead

   Playback of DRM-protected content requires the player to wait for the delivery of a DRM license and content decryption key from the DRM service. DRM license delivery is typically designed to be near-instantaneous, often taking less than 1 second. Many cloud-based multi-DRM systems deliver licenses with a latency below 50ms to 200ms.

   If you want your player to start playback immediately without noticeable latency, you must prepare the content with a clear lead of a few seconds. In this case, the first few seconds of the content remain unencrypted so that the player can begin playback immediately while fetching the required license keys in the background. Using a Clear Lead time of less than 10 seconds is common practice in most cases.

5. Encryption Schemes (cenc, cbcs, cens, cbc1)

   Common Encryption Specification (ISO/IEC 23001-7) defines four protection schemes as follows.

   
   

   Scheme	Description
   cenc	AES CTR scheme
   cbc1	AES CBC scheme
   cbcs	AES-CBC subsample pattern encryption scheme
   cens	AES-CTR subsample pattern encryption scheme

   
   

   Although four encryption modes are defined by the standard, only “cenc” and “cbcs” schemes are used in practice due to limited device support for the others.

   Apple (FairPlay) devices support cbcs scheme only. Legacy Android (Widevine) and Windows (PlayReady) platforms supported only the cenc encryption scheme, while newer platform versions support both cenc and cbcs. This means that using cbcs scheme enables interoperability between major DRMs, Apple FairPlay, Google Widevine, and Microsoft PlayReady, allowing a single encrypted content package to work across Android, Windows, and Apple ecosystems, while some legacy Widevine/PlayReady devices still require cenc.

6. Key Rotation & CPIX Key Exchange

   Key rotation is the process of creating new encryption keys to replace existing keys. By rotating your encryption keys on a regular schedule or after specific events, you can reduce the potential consequences of your key being compromised.

   Key rotation can be used for both file-based (VOD) and live streaming services. Enabling key rotation requires a CPIX document. CPIX is an open specification that defines an interoperable XML-based format for exchanging keys and DRM-related information between systems for various use cases, including key rotation and key exchange between encoders and packagers.

7. Offline Playback

   Offline playback allows users to download and watch DRM-protected content without an active internet connection. This is enabled through persistent DRM licenses. When DRM persistency is enabled, the client stores the DRM license until its expiration time and reuses the locally stored license for offline playback.

8. Output Protection

   Output protection ensures that digital content is not intercepted or copied as it travels from a device to an external device. It enforces hardware-level checks to block unauthorized recording, screen-casting, or mirroring.

   For example, when HDCP output protection is enabled, a set-top box connected to a TV through an HDMI cable can play content only on HDCP-compliant TVs. Output protection can prevent TVs without HDCP support from displaying content, thereby preventing it from being viewed or recorded by unauthorized devices.

3. DRM Guidelines for Dolby Vision

Dolby Vision is agnostic with the DRM technology, so existing industry standards and specifications are sufficient for applying DRM protection to the Dolby Vision content. However, there are device- and ecosystem-related requirements or limitations that must be considered when delivering Dolby content with DRM protection. This section explains those requirements briefly.

1. Encryption Type (Subsample Encryption vs Full sample Encryption)

   Common encryption specification (CENC) defines two type of encryption methods: subsample encryption and full sample encryption.

   Subsample encryption enables partial protection, encrypting only payload data (like video NAL units) while leaving video metadata (headers) in the clear, whereas full sample encryption protects the entire media sample (audio/video frame).

   Dolby Vision contents must be subsample encrypted as defined in second edition of the CENC specification CENCv2 (ISO/IEC 23001-7:2015) or later. The first edition version of the CENC specification CENCv1 (ISO/IEC 23001-7:2012) allows full sample encryption for video NAL units, which causes Dolby Vision video headers not detected properly, resulting in a playback error. This problem has been corrected in CENCv2 (ISO/IEC 23001-7:2015), which requires subsample encryption for video NAL units, leaving video slide headers in the clear so that Dolby Vision video headers are processed properly by the playback device.

2. DRM Security Levels (Hardware-DRM vs Software-DRM)

   Some platforms require H.265/HEVC video content to be protected with hardware-based DRM for content security reasons. If Hardware-DRM is required, then any H.265/HEVC bitstream, including Dolby Vision HEVC, cannot be played on software-based DRM devices. Therefore, you must check target device and platform requirements and use either hardware-DRM or software-DRM for Dolby Vision content delivery.

3. Multi Key or Single Key?

   Some client devices and platforms may require different DRM security levels for audio and video. For example, hardware-based DRM may be required for HEVC video, while software-based DRM may be sufficient for audio. In such cases, the audio and video tracks may need to be encrypted using separate keys. Therefore, the DRM security-level requirements of the target devices should be identified in advance, and the appropriate encryption key -single-key or multi-key- should be selected accordingly.

    

4. DRM Guidelines for Web Browsers on Windows PC

Web browsers have requirements that differ from those of other devices due to the limitations or incompatibilities between browser implementations and device or operating system capabilities. Windows PCs have built-in support for Microsoft PlayReady DRM, which enables web browsers to leverage native PlayReady capabilities for the playback of premium content, including 4K H.265/HEVC Dolby Vision video.

Although Widevine DRM is also available on Windows PCs, H.265/HEVC codec is not supported by the Widevine DRM. This means Chrome browsers cannot use Widevine for playing Dolby Vision HEVC video on Windows PCs and must instead use PlayReady. Because Microsoft PlayReady is the only DRM system that supports H.265/HEVC playback on Windows PCs, this section includes guidelines for PlayReady only.

1. DRM Support Matrix for Web Browsers (Standalone Audio and Video)

   To understand browser playback capabilities and DRM-related requirements, we tested various use cases and summarized the playback test results in the table below as a guideline.

   
   

   Stream(*)	DRM System(**)	Security Level	Encryption Scheme	Clear Lead	Microsoft Edge(***)	Google Chrome(***)
   Dolby Vision Video	PlayReady	Software-DRM (SL2000)	cenc	zero / non-zero	✅ Supported	✖ Not Supported
   Dolby Vision Video	PlayReady	Hardware-DRM (SL3000)	cenc	zero / non-zero	✅ Supported	✅ Supported
   Dolby Vision Video	PlayReady	Software-DRM (SL2000)	cbcs	zero / non-zero	✅ Supported	✖ Not Supported
   Dolby Vision Video	PlayReady	Hardware-DRM (SL3000)	cbcs	zero / non-zero	✅ Supported	✅ Supported
   Dolby Digital Plus with Atmos (EC-3) Audio	PlayReady	Software-DRM (SL2000)	cenc	zero / non-zero	✅ Supported	✖ Not Supported
   Dolby Digital Plus with Atmos (EC-3) Audio	PlayReady	Hardware-DRM (SL3000)	cenc	zero / non-zero	✅ Supported	✖ Not Supported
   Dolby Digital Plus with Atmos (EC-3) Audio	PlayReady	Software-DRM (SL2000)	cbcs	zero / non-zero	✅ Supported	✖ Not Supported
   Dolby Digital Plus with Atmos (EC-3) Audio	PlayReady	Hardware-DRM (SL3000)	cbcs	zero / non-zero	✅ Supported	✖ Not Supported
   AAC Audio	PlayReady	Software-DRM (SL2000)	cenc	zero / non-zero	✅ Supported	✖ Not Supported
   AAC Audio	PlayReady	Hardware-DRM (SL3000)	cenc	zero / non-zero	✅ Supported	✅ Supported
   AAC Audio	PlayReady	Software-DRM (SL2000)	cbcs	zero / non-zero	✅ Supported	✖ Not Supported
   AAC Audio	PlayReady	Hardware-DRM (SL3000)	cbcs	zero / non-zero	✖ Not Supported	✖ Not Supported
   (*) STREAM SETTINGS: Video: HEVC Dolby Vision Profile5 (dvh1.05)  Audio-1: Dolby Digital Plus with Atmos (ec-3) Audio-2: AAC 2-channels (mp4a)		(**) DRM SETTINGS: Encryption Settings-1: CENC with 16-byte IV Encryption Settings-2: CBCS with 16-byte IV Video Track: Sub sample encrypted Audio Tracks: Fully encrypted PlayReady WRMHEADER Version-1 (cenc): v4.0.0.0 PlayReady WRMHEADER Version-2 (cbcs): v4.3.0.0			(***) SYSTEM SETTINGS: Windows 11 v24H2 (64-bit), x64-based Intel Edge v143.0.3650.139 (Official 64bit) Chrome v148.0.7778.179 (Official 64bit)

2. DRM Support Matrix for Web Browsers (Audio and Video Combined)

   When audio and video streams are combined in a single DASH package, the following playback test results are obtained on web-browsers on Windows PC.

   
   

   Video Format*	Audio Format*	DRM System**	Security Level	Encryption Scheme	Microsoft Edge***	Google Chrome***
   Dolby Vision	EC-3	PlayReady	Software-DRM (SL2000)	cenc	✅ Supported	✖ Audio Not Supported
   Dolby Vision	EC-3	PlayReady	Hardware-DRM (SL3000)	cenc	✅ Supported	✖ Audio Not Supported
   Dolby Vision	EC-3	PlayReady	Software-DRM (SL2000)	cbcs	✅ Supported	✖ Audio Not Supported
   Dolby Vision	EC-3	PlayReady	Hardware-DRM (SL3000)	cbcs	✅ Supported	✖ Audio Not Supported
   Dolby Vision	AAC	PlayReady	Software-DRM (SL2000)	cenc	✅ Supported	✖ Audio Not Supported
   Dolby Vision	AAC	PlayReady	Hardware-DRM (SL3000)	cenc	✅ Supported	✅ Supported
   Dolby Vision	AAC	PlayReady	Software-DRM (SL2000)	cbcs	✅ Supported	✖ Audio Not Supported
   Dolby Vision	AAC	PlayReady	Hardware-DRM (SL3000)	cbcs	✖ Audio Not Supported	✖ Audio Not Supported
   (*) STREAM SETTINGS: Video: HEVC Dolby Vision Profile5 (dvh1.05)  Audio-1: Dolby Digital Plus with Atmos (ec-3) Audio-2: AAC 2-channels (mp4a)			(**) DRM SETTINGS: Encryption Settings-1: CENC with 16-byte IV Encryption Settings-2: CBCS with 16-byte IV Video Track: Sub sample encrypted Audio Tracks: Fully encrypted PlayReady WRMHEADER Version-1 (cenc): v4.0.0.0 PlayReady WRMHEADER Version-2 (cbcs): v4.3.0.0		(***) SYSTEM SETTINGS: Windows 11 v24H2 (64-bit), x64-based Intel Edge v143.0.3650.139 (Official 64bit) Chrome v148.0.7778.179 (Official 64bit)

3. Edge Browser–Specific Considerations

   • Edge Browser has built-in support for Microsoft PlayReady DRM and it can handle 4K HEVC Dolby Vision and Dolby Digital Plus with Atmos audio playback with both SL2000 (software-DRM) and SL3000 (hardware-DRM) security levels.
   • Dolby Vision video and Dolby Digital Plus with Atmos audio can be played on Edge browser with both security levels (SL3000 or SL2000) and both encryption schemes (cbcs, cenc)
   • When AAC audio codec is delivered with cbcs encryption and SL3000 security level, audio decoding errors are observed.
   • Edge browser works with both PlayReady Key system strings as shown in below table. 
     
     

     PlayReady Key System	Edge Browser on Windows PC
     com.microsoft.playready.recommendation.3000	✅ Supported Security Level 3000
     com.microsoft.playready.recommendation	✅ Supported Security Level 2000

4. Chrome Browser–Specific Considerations

   • Chrome supports only Hardware secure PlayReady playback on Windows platforms (no Software secure PlayReady playback support). That means, any audio video content, including Dolby Vision video and AAC audio, can be delivered only to client devices with Hardware-based PlayReady DRM support.
   • When delivering Dolby Vision content to Chrome, make sure your PlayReady DRM service distributes DRM licenses with Minimum Security Level of 3000 (i.e. SL3000).
   • During packaging, ensure that the appropriate encryption scheme is selected. As shown in the table "DRM Support Matrix" above, Chrome supports Dolby Vision with both cbcs and cenc schemes, whereas AAC audio works only with cenc when hardware-DRM is enabled. This means that when delivering a stream containing Dolby Vision video and AAC audio for Chrome browser, you must either use the "cenc" encryption scheme or leave the audio unencrypted. 
     
     

     Sample Bento4 Tool Command for packaging Dolby Vision video & AAC audio (encryption = cenc; playready version = 4.0; IV is 16-byte; clearlead = 0)

     /Bento4/bin/mp4dash \ video_dolby_vision_profile5.mp4 \ audio_aac_stereo.mp4 \ --encryption-args="--property 1:ClearLeadFragments:0" \ --encryption-cenc-scheme=cenc \ --encryption-key=XXXXX4190f6740048afa24c717dXXXXX:XXXXXd22dcc550b3cd6a141c691XXXXX:XXXXX4190f6740048afa24c717dXXXXX \ --playready \ --playready-version=4.0 \ --playready-header=#{PLAYREADY_HEADER_VALUE} ... ...

      

   • Chrome, currently does not support Dolby Digital Plus audio (EC-3).
   • Chrome requires the PlayReady Key System string to set to "com.microsoft.playready.recommendation.3000". This key system is supported on devices with required hardware and it enforces hardware security level (SL3000).
     
     

     PlayReady Key System	Chrome Browser on Windows PC
     com.microsoft.playready.recommendation.3000	✅ Supported Security Level 3000
     com.microsoft.playready.recommendation	✖ Not Supported  Security Level 2000

      

   • The player must be configured with correct key system string and security level. See an example player configuration with Shaka-Player below: 
     
     

     Sample Shaka Player Config for playing Dolby Vision with PlayReady Hardware-DRM (SL3000)

     {   "drm": {     "keySystemsMapping": {       "com.microsoft.playready": "com.microsoft.playready.recommendation.3000"     },     "servers": {       "com.microsoft.playready": "PLAYREADY_LA_URL"     },     "advanced": {       "com.microsoft.playready.recommendation.3000": {         "videoRobustness": [           "3000"         ],         "audioRobustness": [           "3000"         ]       }     }   } }

5. Considerations for PlayReady Software-DRM (SL2000)

   • The delivered DRM license must have a Minimum Security level property of 2000. (i.e. software-DRM).
   • Note that cbcs is supported only on hardware-DRM (SL3000) clients. This means "cenc" encrpytion scheme must be used while streaming to client devices with software-DRM support.

6. Considerations for PlayReady Hardware-DRM (SL3000)

   • The delivered DRM license must have a Minimum Security level property of 3000. (i.e. hardware-DRM).
   • In some use-cases, audio must be encrypted with a different content key than video (i.e. multi-key content), and the license used for the audio must have a Minimum Security level property of 2000. Alternatively, audio could be left in the clear, although this is not always recommended because the audio stream would remain unprotected.
   • PlayReady HWDRM for Windows 10 doesn't support down-resolution and will enforce that HDCP is engaged. Microsoft recommends that high definition content for HWDRM have an OPL greater than 270 (although it is not required). Additionally, setting HDCP type restriction in the license (HDCP version 2.2 on Windows 10) is recommended.
   • In HWDRM, output protections are enforced on all monitors based on the least capable monitor. For example, if the user has two monitors connected where one of the monitors supports HDCP and the other does not, playback will fail if the license requires HDCP even if the content is only being rendered on the monitor that supports HDCP.

7. Other Considerations for PlayReady DRM

   • Make sure you choose the correct PlayReady version. PlayReady version support matrix is given below.
     
     

     	PlayReady Header v4.3.0.0	PlayReady Header v4.2.0.0	PlayReady Header v4.1.0.0	PlayReady Header v4.0.0.0
     PlayReady 4.0 SDK Clients (see note 1)	✅ Supported	✅ Supported	✅ Supported	✅ Supported
     PlayReady 3.0 SDK Clients (see note 2)		✅ Supported	✅ Supported	✅ Supported
     PlayReady 2.x SDK Clients (see note 3)			✅ Supported	✅ Supported
     PlayReady 1.x SDK Clients (see note 4)				✅ Supported
     Notes: 1-) Xbox One version 1709 or higher are PlayReady 4.X Clients. 2-) Windows 10 (all versions) and Xbox One version 1703 or lower are PlayReady 3.X Clients. Newest non-Windows devices (for example, Smart TVs) released after 2017 are PlayReady 3.X Clients. 3-) Silverlight and Windows 8, 8.1 are PlayReady 2.X Clients. Most non-Windows devices (for example, Smart TVs) released between 2011 and 2017 are PlayReady 2.X Clients. 4-) Most non-Windows devices (for example, Smart TVs) released between 2008 and 2011 are PlayReady 1.X Clients.

   
   
   • Make sure you choose the right encryption scheme during packaging the content. PlayReady clients built on or after PlayReady version 4.0 support "cbcs" encryption mode, whereas "cenc" encryption mode is fully supported across all versions of PlayReady, browsers, and devices (including older clients and Windows/Xbox ecosystems).
   • Windows Clients support AESCBC mode (e.g. cbcs) only on hardware-DRM (SL3000) units. Generating a license with AESCBC key when the incoming client certificate is SL2000 throws an exception.
   • Make sure not using AESCBC key for devices that uses a PlayReady Porting Kit version prior to 4.0. When the incoming client certificate is a device that uses a Porting Kit version prior to 4.0, generating a license with a CBC key will throw an exception.
   • Make sure not using a AESCBC (i.e. cbcs) key for devices that does not indicate support for AESCBC. When the incoming license request does not indicate support for AESCBC, generating a license with a CBC key will throw an exception.
   • The keys used to encrypt the different tracks and qualities of an asset must be same, either cenc (AESCTR) or cbcs (AESCBC).
   • Services must not encrypt a single piece of content both in AESCTR mode and in AESCBC mode using the same KeyID. This is because a client acquiring a license with same KeyID for both AESCTR and AESCBC would not function.
   • For compatibility reasons, 128-bit IVs (16-byte IVs) are recommended for both AESCTR and AESCBC encryption modes. Starting with PlayReady version 4.0, HLS compliant streams that use 128-bit IVs in CBC mode and HBBTV conformant streams with 128-bit IVs in CTR mode are supported.
   • PlayReady header should have either all ALGID values for each KeyID elements to be same or do not have any ALGID value.
   • PlayReady systems with version 1.X, 2.X and 3.X can only protect files encrypted in CTR mode (Common Encryption mode 'cenc'). 'cens' is not supported. PlayReady systems with version 4.0 and higher can protect files encrypted in CTR mode (Common Encryption modes 'cenc') and in CBC mode (Common Encryption modes 'cbcs'). The other modes 'cens' and 'cbc1' are not supported.
   • Hardware-based PlayReady DRM is supported on a multitude of devices, including both Windows and non-Windows devices such as TV sets, phones, and tablets. For a Windows device to support PlayReady Hardware DRM, it must be running Windows 10 or later and have a supported hardware configuration.