Frequently Asked Questions


We have collected some key questions - and the associated answers - that deal with how Digital Rights Management (DRM) is used in the video services marketplace today. We hope you find the information we have collected here useful, but if you have additional questions on this general topic please don’t hesitate to send us a note (using the form at the bottom of this page) and we will add additional answers (and give you the credit!)

It may also be useful to peruse the following 2 documents:
DRM 101: What is DRM and How Does it Work?
DRM Simplified: The EZDRM Solution
AWS Solution Brief: Multi-DRM in the AWS Elemental Cloud-Based Video Workflow


  • What is DRM as a Service (DRMaaS)?
  • How is DRMaaS Managed?
  • Why is DRM useful to distribute video content?
  • What does video encryption protect?
  • What is watermarking?
  • What is MPEG-DASH and DASH-IF?
  • What is Common Encryption (CENC)?
  • What is CMAF - Common Media Application Format?
  • Where does video encryption happen?
  • What is CPIX - Content Protection Information Exchange?
  • Is SPEKE the same thing as CPIX?
  • Should I use an in-browser player or player applications?
  • Which browsers support DRM for video services?
  • What are Encrypted Media Extensions (EME)?
  • What is a Content Decryption Module (CDM)?
  • What is DRM hardware security?
  • What is a DRM license request?
  • What is the difference between a persistent and a non-persistent (transient) license?
  • What is delivered during a DRM license request?
  • What is Adaptive Bit Rate (ABR)?
  • What is HTTP Live Streaming (HLS)?

When you are setting up a video service, there are many components to put into place. In past years, the deployment model required investing in a specialist data center and racks of equipment to do video acquisition, video encoding, subscriber management, security and so on. The predominant model in today's market is to use an integrated suite of cloud-based components to provide the same functions - but without the fan noise!
Since DRM is a specialized area and needs specific attention to licensing and security, amongst other things, the model of access to a cloud-based micro-service, that supports the DRM function you need, is a very convenient simplification of the overall deployment setup.
The benefits of using a service for DRM implementation include:

  • No capital costs - payment primarily on a transactional, periodic basis that scales with the use of the service.
  • Fast time to market - the infrastructure is already set up and only requires integration logic to tie to the rest of the service workflow.
  • Easy integration - well documented and fully tested templates.
  • Easy scaling - the management of the service includes the addition of resources as your viewership grows.
  • Access to specialist expertise when required - you always have someone available to keep things running at peak performance.

DRM as a Service is a fully managed software solution, which means that you, as a video service provider, do not need to be concerned about:

  • System setup - all initial service configuration and reporting management is undertaken as you set up your account.
  • Security - all system data is maintained in a fully hardened environment, so there is no concern over unauthorized access to key data or business critical transactions.
  • Personally identifiable data - limited by design in order to comply with privacy regulations.
  • Monitoring - the management of service operation is covered by expert engineers on a 24/7/365 basis. Any issues that arise with operation or performance are flagged and resolved before becoming business critical.
  • Resilience - using state of the art cloud resource management techniques, resiliency and redundancy is automatically addressed. Issues that arise with communications or compute resources are resolved in real time.
  • Upgrades - an important part of this business is keeping up to date with the evolving technology. As the DRM versions from the various vendors evolve and new features are released the integrated service can be ready on day one.
DRMaaS is accessed by an easily implemented API from the encoder or packager solution in use. The majority of commercial encoder/packager solutions are already supported by EZDRM.

Anyone in the business of commercial video distribution - in the enterprise or entertainment or education space - should be fully aware of the imperative to protect such video from unauthorized copying or re-distribution. If you don't have any protection in place, its hard to create a business around the video service.
The movie and TV industry is especially protective of their video assets and, if you try and license such assets for your service, they impose strict rules on distribution to ensure that appropriate security is in place. DRM solutions are the core of such protection mechanisms - and the DRM mechanisms are used to encrypt video before distribution AND control the distribution of the vital decryption keys to limit viewership to the intended devices and consumers. For more information on this, see our DRM Comparison page.
DRM requirements can vary with the quality (or value) of the assets being licensed. And these requirements can limit what content can be delivered across devices such as PCs, smart phones and tablets for example. In general, SD (480p) playback can utilize software-based DRM while HD (720p+) playback typically requires a hardware enhanced DRM implementation (see FAQ section on Hardware Security). Providing 4K/UHD quality content also requires hardware-secured DRM along with additional security requirements beyond DRM, including watermarking (see FAQ section on Watermarking below).

Compressed video and audio playback is universally supported on today's computers and consumer hardware. But the process of compression makes the data in the video file or stream exceptionally sensitive to alterations in its binary content – only minor corruption of the video data is needed to have a massive ripple effect on the decompression and rendering functions. You can see that sometimes when a video you are watching glitches somehow and dissolves into a mass of seemingly randomly colored pixels. Such data changes that disrupt the playback function can happen accidentally - when communication protocols break for example. Or the video can be “corrupted” deliberately at its source by partially or completely encrypting the content using a scrambling key. Unlike random corruption of files or streams, this encryption is a very precise process using controlled scrambling key data and a well-defined algorithm. The whole design concept of this encryption process is that it is, of necessity, 100% reversible. With this premise, under the right circumstances, it is possible to reconstruct the original high-quality source material from the scrambled stream or file.
Scrambled/encrypted video content is essentially valueless without knowledge of how to reverse the encryption process. It can’t be played or redistributed. Effectively scrambled video content often uses a different scrambling key for each time period of a live stream, and certainly for every individual video asset in a library. Reversing the encryption process, of course, requires access to the scrambling key or keys used for protection and knowledge of the algorithm used. Controlling this access is the essence of video security and why it is core to the video service business.

When video content is watermarked - typically during encoding, but also potentially at time of individual delivery or even during specific device playback - it means that some form of copy identifier information (often termed a payload) is added to the video, which will be included in any copies that are made. The identifier payload is - by design - intended to be subliminal or imperceptible so that it does not interfere with the viewing experience. But because any potential illegal copies also carry the payload, watermarking provides an additional form of security mechanism that extends beyond the envelope of encrypted delivery. For more general information on video watermarking please refer to the Digital Watermarking Alliance http://digitalwatermarkingalliance.org

In April 2012, ISO, the international standards body which had already given us the core media foundations of MPEG-2, MP3 and MP4, finally ratified the version of an adaptive streaming standard: MPEG-DASH (DASH stands for Dynamic Adaptive Streaming using HTTP). The participating companies in the MPEG-DASH standardization (including Microsoft, Apple, Netflix, Qualcomm, Ericsson, Samsung, and many others) saw a vision of interoperability and convergence required for large-scale market growth in streaming video that trumped the prior emphasis on proprietary and competing streaming formats based around HTTP. In terms of sophistication and flexibility, DASH leapfrogged the existing multiple proprietary solutions with a single industry-defined open standard.
Of course, a standard document typically only marks the beginning of the work of detailed interoperable usage - and so the baton for a lot of practical effort was passed to an industry forum to promote and catalyze the adoption of MPEG-DASH. The DASH Industry Forum (DASH-IF) is filled with member companies who are realists about the DASH deployment challenges. EZDRM is a member of the DASH-IF. Member companies are willing to take on the work of creating recommendations, filing bugs, and attending plug-fests and interop events, with the belief that their business and the Internet streaming market in large will benefit a great deal with convergence around the DASH format. For further information see https://dashif.org

To try and help reduce fragmentation of the video delivery equipment and software market, a standardized algorithm for streaming video file encryption has been created. It is called Common Encryption (also referred to as CENC). CENC is an ISO 23001-7 standard (http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=68042) that defines how encryption will be applied to different sections of a video file format and what scrambling algorithm will be used with the encryption key(s). Ultimately, the CENC format enables the same secure content to be distributed to numerous playback devices/platforms, all of which can use the defined algorithm to restore the content to playable form. What isn't standardized in CENC is how the scrambling keys themselves will be delivered to the playback device - this is left to the technology of distinct DRM clients in each device. Individual DRM clients retain responsibility for the security of aspects such as license distribution, rights mapping, and compliance which means these processes can be implemented in a proprietary fashion in individual DRM systems. See the FAQ section on License Delivery.

The Common Media Application Format (CMAF; officially MPEG-A Part 19 or ISO/IEC Standard 23000-19 - https://www.iso.org/standard/71975.html) is a newer initiative that builds on MPEG-DASH standardization, but also attempts to reconcile the de-facto adaptive streaming standard (HLS as defined, implemented and evolved by Apple) with some of the DASH related advances and move the ball forward to a truly secure common file format that can be used as the origin of all streaming delivery.
See our full discussion of the significance of CMAF in this recent white paper.

In most streaming video workflows, the option to encrypt video is a processing step between the output of the video encoder and the input of the distribution platform. The operations that are often combined are the segmentation of video streaming into delivery packets, running the encryption algorithm over those packets and the building of a manifest file that references both the packets and the identifiers necessary for video players to request the decryption keys. The overall operation is sometimes termed packaging. When a DRM is being used, the keys are in general requested from the DRM service (which assures appropriate randomization etc.) and paired at that point with the content identifiers to be used to retrieve those keys at playback. Wherever the keys are generated, the storage of those keys is wholly trusted to the DRM service.
While it makes the most sense, from a security perspective, to have video stored in a protected format at the origin of a CDN for example, there are also examples of Just In Time (JIT) packaging systems where the various packaging steps are triggered in real-time by end-user device requests and where, because of this real-time treatment, the process can adapt to specific device requirements.

CPIX stands for Content Protection Information Exchange, a rather bland term for a standard that brings very exciting changes for the media industry. Driven by the DASH Industry Forum, CPIX is designed to create operational efficiencies and reduce the launch time for your OTT services. More information is available through the DASH-IF Interoperability Documents.
CPIX is used as a base mechanism to exchange keys and DRM policies between the DRM service key manager and encryptors or packagers. Historically, every vendor used its own proprietary interface and sometimes DRM-specific APIs to handle this information exchange. Hence, switching from one solution to another could be complex and error prone. CPIX has become a common denominator in such interfaces. In that sense CPIX breaks the vendor lock-in for operators.
A feature of CPIX that is becoming increasingly useful for premium services is the ability to specify a multi-key encryption process. CPIX multi-key serves to protect stream content at different resolutions with different key values so that, for example, a variety of business models can be supported with a single stream asset. See more details read about our Multi-Key implementation with our partner Unified Streaming.
Unlike some prior efforts, which tended to try and focus on a streaming single ecosystem, CPIX addresses both DASH and HLS streaming protocols. This enables operators who adopt CPIX to securely stream video to virtually every type of connected device.

Building on the standardization effort with SPEKE, AWS introduced the Secure Packager and Encoder Key Exchange, or SPEKE for short. SPEKE is an open API specification that fully streamlines the way Digital Rights Management (DRM) systems integrate with packers and encryptors (in the SPEKE context “encryptors” encompass encoders, transcoders, and origin servers that interact with DRM systems to obtain and use encryption keys).
SPEKE delivers a standardized API for key exchange between encryptors and DRM systems for both live and on-demand media workflows, while allowing media customers to use any SPEKE-enabled key server or encryptor in on-premises, cloud, or hybrid infrastructures. SPEKE incorporates the CPIX specification and builds this foundation to address practical issues, such as service authentication. As such, the API eliminates the need for complex integrations between proprietary multi-DRM APIs and encryptors from different vendors. SPEKE-enabled DRM services should work with any SPEKE-enabled encryptors out of the box. SPEKE supports HLS, MSS, and DASH with DRM solutions including Apple Fairplay, Microsoft PlayReady, Google Widevine and proprietary DRMs, as well as AES-128 encryption. More than a dozen vendors have already endorsed or demonstrated use of SPEKE.

How a given service chooses to present its video on any given device - and the accompanying elements of the service's user interface is a very important question, but one that sometimes has political as well as technical overtones. In general, downloadable apps are used for commercial video services on mobile devices, tablets and TVs, while desktop/laptop computers often use a browser environment. There's a lot of debate over the merits of the two approaches in terms of user experience - considering startup time, service latency and device efficiency for example. The standardized video formats of MPEG-DASH were originally typically defined around the need for in browser consumption although the usage profile is very much a moving target at the present time.

Modern browser environments from different vendors on each consumer platforms have adopted the HTML5 principle of including support for video more or less directly as a part of their native code and then extending that support to provide mechanics for playback of DRM protected video (see FAQ section on Encrypted Media Extensions below). You should also refer to the table on our DRM comparison page.

Encrypted Media Extensions are a set of JavaScript API specifications that provide a method for the code of web pages to interact with DRM license servers and the inbuilt security mechanisms of browsers (see FAQ section on CDMs) to play back DRM protected video within a web page. A long-standing political tussle has delayed formal standardization of these APIs by the W3C, but de-facto support exists in all commercial browsers. For more information, see the EME specification at https://dvcs.w3.org/hg/html-media/raw-file/tip/encryptedmedia/encrypted-media.html

A Content Decryption Module is an implementation of proprietary DRM client code inside a browser that lies behind the standardized EME implementation. As originally conceived, any browser could support multiple CDM implementations, but politics and commercial rivalry has limited each of today's commercial offerings to support of a single CDM and therefore a single DRM format. Given the way that MPEG-DASH streams and the use of CENC interact, this is not as limiting as it may sound - but it is important to operate an MPEG-DASH video service alongside a Universal DRM service to provide a seamless consumer playback experience.

DRM functionality in devices can be supported wholly via software by building it into a device’s operating system or a library module. Some devices have DRM clients that have been integrated in a way that uses security features of the underlying chipset. This provides a ‘hardware protection’ layer to the logic of the DRM client and protects any decryption keys or unencrypted video from being intercepted by malicious code running in parallel with the DRM client software. The hardware support is offered by ARM TrustZone or another secure processor element at the device level. The details of how security is implemented at this level are beyond the scope of this FAQ, but fundamentally it ties to a hardware implemented, individualized shared secret related to the identifier of the chipset. Hardware root of trust is another way you may hear someone refer to hardware DRM.

The security of encryption keys would be easily compromised, if the communication between a DRM client on a client device and the secure DRM key service was not itself heavily protected. To address this, the encryption keys are frequently delivered in the form of an encrypted object known as a DRM license. It is convenient to include, wrapped up in this same protected license object, some rules about any restrictions on use of the keys (such as a rental period etc.), but for the most part the license simply is a way to deliver the requested key information in an opaque blob.
In fact, the concept of a license file is pretty anachronistic and dates from the origination of digital audio and video distribution, where the objective of a DRM system was to protect downloaded files in an almost wholly offline consumption model. With today’s near continuous online streaming model, it might be a lot more straightforward to check user rights in real time during any section of the playback of content – the historical precedent leads to a number of undesirable effects in media system such as the inability to rescind the issue of a license. It does however provide a way to distinguish between transient and persistent rights for content consumption.
Check out our Demos to see this process in action.

In a commercial video service, the video content itself is scrambled using one or more encryption keys (see FAQ section on Video Encryption), which are stored separately from the encrypted video. However, the encrypted video content must contain a cleartext identifier of the DRM system or systems where the key can be obtained (typically a URL) together with an identifier (often numerical) that can be used to select the right key from the database maintained by that DRM system.
Without going to far into the details of video player logic, when a video player (web browser or app) attempts to render an encrypted video stream, the video player process recognizes the need for a license and requests the local DRM client code agent to obtain that license from the remote DRM service. The request made to the remote service contains client details that can used to assess whether or not this client has the rights to play this content at this time. If the license request succeeds, the critical key information can be extracted by the DRM client and offered to the video player process to enable decryption and video viewing.
Check out our Demos to see this process in action.

Generally, non-persistent licenses are used for immediate playback of content and can also be thought of as “in-memory” licenses. Non-persistent licenses are intended to last for only as long as the current session and are most frequently used within a browser.
Persistent licenses can be stored on a client device after they are received, and are used for any current playback session or at any point thereafter until some time-based rights restriction embedded in the license is reached. So a persistent license, for example, can be used to play back downloaded content while the device is offline. Enforcing protection mechanisms in these scenarios require a local trusted reference for time.
Both persistent and non-persistent licenses include a range of rights and right restrictions set by the content licensor.

Adaptive Bit-Rate (ABR) streaming has been a core enabler of the streaming video revolution by offering a way to deliver a good user video consumption experience across a wide variety of networks and device types. ABR created a way to solve a number of practical problems with first generation video delivery systems and the IP protocols they used, including traversal of in-home broadband routers, security and inconsistent user experiences.
From a technical point of view, ABR is a method of video streaming that uses HTTP as a core protocol and where the source content is encoded at multiple bit rates, then each of the different bit rate streams are sliced into small multi-second segments. The streaming client is informed of the various available streams bit rates using a coordinating file termed a manifest. A client device initially reads the manifest and uses that information to request initial segments of video. During the request process, the time taken to download each segment is measured. If the client finds the download speed permits use of a higher quality, higher bitrate stream, then it “gears up” to request those segments. Conversely if the download time is longer than it would take to play a high-quality segment, the client “gears down” to request smaller, lower bitrate segments. Segments themselves are encoded in such a way that the “joins” become invisible to the viewer, so the client can over time optimize the download rate and viewer quality and adjust to compensate for any short-term variations in bandwidth. Since the optimization is continuously in-progress and undertaken from the client devices point of view, the technique is very effective at providing a viewer experience that’s free from stalls and glitches.
Although originally commercialized by Move networks, ABR came to prominence – or even dominance – through implementations by Microsoft (Smooth Streaming), Apple (HTTP Live Streaming) and in the MPEG-DASH standard.

HTTP Live Streaming (HLS) is an Adaptive Bit-Rate (ABR) streaming communications protocol implemented by Apple that became core to the video system on iPhone and iPad devices. HLS naturally supports both live and on-demand content streams, where the segments of video at the various bitrates were historically created in “chunks” of small MPEG2-TS files. The manifest file is a text file with an .m3u8 extension (based on prior MP3 streaming formats). Apple standardized the format through draft IETF RFC documents and these documents have gone through many revisions. As a practical matter, the HLS format has been wildly popular for streaming video services and likely still dominates the delivery world.
HLS natively supports Fairplay DRM, created by Apple. Learn more about our Fairplay Streaming (FPS) offering here.

Do you have questions we did not answer? Please let us know and we will be happy to answer them for you.