Drm hls

Drm hls DEFAULT

Multi-DRM protected HLS and DASH from a shared CMAF source¶

This tutorial describes how to create the 'holy grail' of packaging: using the same media segments to serve both DASH and HLS, with content protection by all three major DRM systems (FairPlay, PlayReady and Widevine).

The output is a set of encrypted CMAF media tracks, along with HLS and DASH manifests that reference these tracks with all DRM signaling included. The tracks are encrypted with different keys to allow for different levels of DRM protection for HD or 4K content.

This tutorial makes use of functionality that was added in CPIX 2.2, for which support was added in version 1.10.16.

Demo content¶

For this tutorial you will need the Tears of Steel content used for evaluation: Your own Video on Demand demo.

Requirement: CPIX¶

The use of CPIX is required for this workflow, as it is the only way in which specifying the 'cbcs' encryption scheme for DASH output is supported. See CPIX Document Requirements for more information.

The CPIX document shown below uses keys that work with the publicly available Widevine and PlayReady test servers. As there is no easily available FairPlay test server, this setup uses a simple key server that provides the decryption key in the clear for Safari and iOS clients (technically making the stream SAMPLE-AES instead of FairPlay protected, but the set up process is exactly the same).

To work with below CPIX document, save in the same location as your directory with the demo content.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144
<?xml version='1.0' encoding='UTF-8'?><CPIXxmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns="urn:dashif:org:cpix"xsi:schemaLocation="urn:dashif:org:cpix cpix.xsd"><!-- Content Keys are listed with their encryption scheme set to "cbcs", and each with explicit IVs to support FairPlay --><ContentKeyList><ContentKeykid="3f0f9c37-bc82-5742-a780-71caaad6d23b"commonEncryptionScheme="cbcs"explicitIV="Pw+cN7yCV0KngHHKqtbSOw=="><Data><pskc:Secret><pskc:PlainValue>L0pOSrzvkYW/KUnCq9qPZw==</pskc:PlainValue></pskc:Secret></Data></ContentKey><ContentKeykid="4e2d509a-753f-5e26-b253-cb7d21c3bf05"commonEncryptionScheme="cbcs"explicitIV="Ti1QmnU/XiayU8t9IcO/BQ=="><Data><pskc:Secret><pskc:PlainValue>R5Q8JaTx5kARhP+cf9TYBg==</pskc:PlainValue></pskc:Secret></Data></ContentKey><ContentKeykid="80964b5a-22dc-5c93-b18d-8c68b9fb8fc0"commonEncryptionScheme="cbcs"explicitIV="gJZLWiLcXJOxjYxoufuPwA=="><Data><pskc:Secret><pskc:PlainValue>IUCA6yDhHCkv2mD7AV+O3Q==</pskc:PlainValue></pskc:Secret></Data></ContentKey><ContentKeykid="6653b449-e474-5b74-9973-1d8e15fdf0d2"commonEncryptionScheme="cbcs"explicitIV="ZlO0SeR0W3SZcx2OFf3w0g=="><Data><pskc:Secret><pskc:PlainValue>WIvnfHWl+E3Fi64HSvUVmg==</pskc:PlainValue></pskc:Secret></Data></ContentKey><ContentKeykid="47ed9111-3ef1-5511-92fc-54165fc40f91"commonEncryptionScheme="cbcs"explicitIV="R+2RET7xVRGS/FQWX8QPkQ=="><Data><pskc:Secret><pskc:PlainValue>Ilcitl7TYN4d2cPydXiqdQ==</pskc:PlainValue></pskc:Secret></Data></ContentKey></ContentKeyList><DRMSystemList><!-- Widevine DRM with PSSH and empty ContentProtectionData and HLSSignalingData elements, to trigger Packager to generate it --><DRMSystemkid="3f0f9c37-bc82-5742-a780-71caaad6d23b"systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed"><PSSH>AAAAMnBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAABIiCmhvbHlfZ3JhaWxI49yVmwY=</PSSH><ContentProtectionData></ContentProtectionData><HLSSignalingDataplaylist="media"></HLSSignalingData><HLSSignalingDataplaylist="master"></HLSSignalingData></DRMSystem><!-- PlayReady DRM with PSSH and empty ContentProtectionData and HLSSignalingData elements, to trigger Packager to generate it --><DRMSystemkid="3f0f9c37-bc82-5742-a780-71caaad6d23b"systemId="9a04f079-9840-4286-ab92-e65be0885f95"><PSSH></PSSH><ContentProtectionData></ContentProtectionData><HLSSignalingDataplaylist="media"></HLSSignalingData><HLSSignalingDataplaylist="master"></HLSSignalingData></DRMSystem><!-- SAMPLE-AES protection with HLSSignalingData containing the base64 encoded #EXT-X-KEY tag, as Packager cannot generate it --><DRMSystemkid="3f0f9c37-bc82-5742-a780-71caaad6d23b"systemId="94ce86fb-07ff-4f43-adb8-93d2fa968ca2"><HLSSignalingDataplaylist="media">I0VYVC1YLUtFWTpNRVRIT0Q9U0FNUExFLUFFUyxVUkk9aHR0cHM6Ly9rZXlzZXJ2ZXIudW5pZmllZC1zdHJlYW1pbmcuY29tL2tleS9MMHBPU3J6dmtZV19LVW5DcTlxUFp3PT0sS0VZRk9STUFUPWlkZW50aXR5LElWPTB4M0YwRjlDMzdCQzgyNTc0MkE3ODA3MUNBQUFENkQyM0I=</HLSSignalingData><HLSSignalingDataplaylist="master">I0VYVC1YLVNFU1NJT04tS0VZOk1FVEhPRD1TQU1QTEUtQUVTLFVSST1odHRwczovL2tleXNlcnZlci51bmlmaWVkLXN0cmVhbWluZy5jb20va2V5L0wwcE9Tcnp2a1lXX0tVbkNxOXFQWnc9PSxLRVlGT1JNQVQ9aWRlbnRpdHksSVY9MHgzRjBGOUMzN0JDODI1NzQyQTc4MDcxQ0FBQUQ2RDIzQg==</HLSSignalingData></DRMSystem><DRMSystemkid="4e2d509a-753f-5e26-b253-cb7d21c3bf05"systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed"><PSSH>AAAAMnBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAABIiCmhvbHlfZ3JhaWxI49yVmwY=</PSSH><ContentProtectionData></ContentProtectionData><HLSSignalingDataplaylist="media"></HLSSignalingData><HLSSignalingDataplaylist="master"></HLSSignalingData></DRMSystem><DRMSystemkid="4e2d509a-753f-5e26-b253-cb7d21c3bf05"systemId="9a04f079-9840-4286-ab92-e65be0885f95"><PSSH></PSSH><ContentProtectionData></ContentProtectionData><HLSSignalingDataplaylist="media"></HLSSignalingData><HLSSignalingDataplaylist="master"></HLSSignalingData></DRMSystem><DRMSystemkid="4e2d509a-753f-5e26-b253-cb7d21c3bf05"systemId="94ce86fb-07ff-4f43-adb8-93d2fa968ca2"><HLSSignalingDataplaylist="media">I0VYVC1YLUtFWTpNRVRIT0Q9U0FNUExFLUFFUyxVUkk9aHR0cHM6Ly9rZXlzZXJ2ZXIudW5pZmllZC1zdHJlYW1pbmcuY29tL2tleS9SNVE4SmFUeDVrQVJoUC1jZjlUWUJnPT0sS0VZRk9STUFUPWlkZW50aXR5LElWPTB4NEUyRDUwOUE3NTNGNUUyNkIyNTNDQjdEMjFDM0JGMDU=</HLSSignalingData><HLSSignalingDataplaylist="master">I0VYVC1YLVNFU1NJT04tS0VZOk1FVEhPRD1TQU1QTEUtQUVTLFVSST1odHRwczovL2tleXNlcnZlci51bmlmaWVkLXN0cmVhbWluZy5jb20va2V5L1I1UThKYVR4NWtBUmhQLWNmOVRZQmc9PSxLRVlGT1JNQVQ9aWRlbnRpdHksSVY9MHg0RTJENTA5QTc1M0Y1RTI2QjI1M0NCN0QyMUMzQkYwNQ==</HLSSignalingData></DRMSystem><DRMSystemkid="80964b5a-22dc-5c93-b18d-8c68b9fb8fc0"systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed"><PSSH>AAAAMnBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAABIiCmhvbHlfZ3JhaWxI49yVmwY=</PSSH><ContentProtectionData></ContentProtectionData><HLSSignalingDataplaylist="media"></HLSSignalingData><HLSSignalingDataplaylist="master"></HLSSignalingData></DRMSystem><DRMSystemkid="80964b5a-22dc-5c93-b18d-8c68b9fb8fc0"systemId="9a04f079-9840-4286-ab92-e65be0885f95"><PSSH></PSSH><ContentProtectionData></ContentProtectionData><HLSSignalingDataplaylist="media"></HLSSignalingData><HLSSignalingDataplaylist="master"></HLSSignalingData></DRMSystem><DRMSystemkid="80964b5a-22dc-5c93-b18d-8c68b9fb8fc0"systemId="94ce86fb-07ff-4f43-adb8-93d2fa968ca2"><HLSSignalingDataplaylist="media">I0VYVC1YLUtFWTpNRVRIT0Q9U0FNUExFLUFFUyxVUkk9aHR0cHM6Ly9rZXlzZXJ2ZXIudW5pZmllZC1zdHJlYW1pbmcuY29tL2tleS9JVUNBNnlEaEhDa3YybUQ3QVYtTzNRPT0sS0VZRk9STUFUPWlkZW50aXR5LElWPTB4ODA5NjRCNUEyMkRDNUM5M0IxOEQ4QzY4QjlGQjhGQzA=</HLSSignalingData><HLSSignalingDataplaylist="master">I0VYVC1YLVNFU1NJT04tS0VZOk1FVEhPRD1TQU1QTEUtQUVTLFVSST1odHRwczovL2tleXNlcnZlci51bmlmaWVkLXN0cmVhbWluZy5jb20va2V5L0lVQ0E2eURoSENrdjJtRDdBVi1PM1E9PSxLRVlGT1JNQVQ9aWRlbnRpdHksSVY9MHg4MDk2NEI1QTIyREM1QzkzQjE4RDhDNjhCOUZCOEZDMA==</HLSSignalingData></DRMSystem><DRMSystemkid="6653b449-e474-5b74-9973-1d8e15fdf0d2"systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed"><PSSH>AAAAMnBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAABIiCmhvbHlfZ3JhaWxI49yVmwY=</PSSH><ContentProtectionData></ContentProtectionData><HLSSignalingDataplaylist="media"></HLSSignalingData><HLSSignalingDataplaylist="master"></HLSSignalingData></DRMSystem><DRMSystemkid="6653b449-e474-5b74-9973-1d8e15fdf0d2"systemId="9a04f079-9840-4286-ab92-e65be0885f95"><PSSH></PSSH><ContentProtectionData></ContentProtectionData><HLSSignalingDataplaylist="media"></HLSSignalingData><HLSSignalingDataplaylist="master"></HLSSignalingData></DRMSystem><DRMSystemkid="6653b449-e474-5b74-9973-1d8e15fdf0d2"systemId="94ce86fb-07ff-4f43-adb8-93d2fa968ca2"><HLSSignalingDataplaylist="media">I0VYVC1YLUtFWTpNRVRIT0Q9U0FNUExFLUFFUyxVUkk9aHR0cHM6Ly9rZXlzZXJ2ZXIudW5pZmllZC1zdHJlYW1pbmcuY29tL2tleS9XSXZuZkhXbC1FM0ZpNjRIU3ZVVm1nPT0sS0VZRk9STUFUPWlkZW50aXR5LElWPTB4NjY1M0I0NDlFNDc0NUI3NDk5NzMxRDhFMTVGREYwRDI=</HLSSignalingData><HLSSignalingDataplaylist="master">I0VYVC1YLVNFU1NJT04tS0VZOk1FVEhPRD1TQU1QTEUtQUVTLFVSST1odHRwczovL2tleXNlcnZlci51bmlmaWVkLXN0cmVhbWluZy5jb20va2V5L1dJdm5mSFdsLUUzRmk2NEhTdlVWbWc9PSxLRVlGT1JNQVQ9aWRlbnRpdHksSVY9MHg2NjUzQjQ0OUU0NzQ1Qjc0OTk3MzFEOEUxNUZERjBEMg==</HLSSignalingData></DRMSystem><DRMSystemkid="47ed9111-3ef1-5511-92fc-54165fc40f91"systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed"><PSSH>AAAAMnBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAABIiCmhvbHlfZ3JhaWxI49yVmwY=</PSSH><ContentProtectionData></ContentProtectionData><HLSSignalingDataplaylist="media"></HLSSignalingData><HLSSignalingDataplaylist="master"></HLSSignalingData></DRMSystem><DRMSystemkid="47ed9111-3ef1-5511-92fc-54165fc40f91"systemId="9a04f079-9840-4286-ab92-e65be0885f95"><PSSH></PSSH><ContentProtectionData></ContentProtectionData><HLSSignalingDataplaylist="media"></HLSSignalingData><HLSSignalingDataplaylist="master"></HLSSignalingData></DRMSystem><DRMSystemkid="47ed9111-3ef1-5511-92fc-54165fc40f91"systemId="94ce86fb-07ff-4f43-adb8-93d2fa968ca2"><HLSSignalingDataplaylist="media">I0VYVC1YLUtFWTpNRVRIT0Q9U0FNUExFLUFFUyxVUkk9aHR0cHM6Ly9rZXlzZXJ2ZXIudW5pZmllZC1zdHJlYW1pbmcuY29tL2tleS9JbGNpdGw3VFlONGQyY1B5ZFhpcWRRPT0sS0VZRk9STUFUPWlkZW50aXR5LElWPTB4NDdFRDkxMTEzRUYxNTUxMTkyRkM1NDE2NUZDNDBGOTE=</HLSSignalingData><HLSSignalingDataplaylist="master">I0VYVC1YLVNFU1NJT04tS0VZOk1FVEhPRD1TQU1QTEUtQUVTLFVSST1odHRwczovL2tleXNlcnZlci51bmlmaWVkLXN0cmVhbWluZy5jb20va2V5L0lsY2l0bDdUWU40ZDJjUHlkWGlxZFE9PSxLRVlGT1JNQVQ9aWRlbnRpdHksSVY9MHg0N0VEOTExMTNFRjE1NTExOTJGQzU0MTY1RkM0MEY5MQ==</HLSSignalingData></DRMSystem></DRMSystemList><!-- Rules mapping the different keys to different tracks --><ContentKeyUsageRuleList><ContentKeyUsageRulekid="3f0f9c37-bc82-5742-a780-71caaad6d23b"><VideoFiltermaxPixels="442368"/></ContentKeyUsageRule><ContentKeyUsageRulekid="4e2d509a-753f-5e26-b253-cb7d21c3bf05"><VideoFilterminPixels="442369"maxPixels="2073600"/></ContentKeyUsageRule><ContentKeyUsageRulekid="80964b5a-22dc-5c93-b18d-8c68b9fb8fc0"><VideoFilterminPixels="2073601"maxPixels="8847360"/></ContentKeyUsageRule><ContentKeyUsageRulekid="6653b449-e474-5b74-9973-1d8e15fdf0d2"><VideoFilterminPixels="8847361"/></ContentKeyUsageRule><ContentKeyUsageRulekid="47ed9111-3ef1-5511-92fc-54165fc40f91"><AudioFilter/></ContentKeyUsageRule></ContentKeyUsageRuleList></CPIX>

Creating DASH client manifest (MPD)¶

For DASH only a single client manifest is required. For this you can enable the option to make sure that explicit DRM information is included in the MPD:

#!/bin/bash mp4split -o dash-cbcs.mpd \ --cpix multi-format-drm.cpix \ --mpd.inline_drm \ tears-of-steel-aac-64k.cmfa \ tears-of-steel-avc1-400k.cmfv \ tears-of-steel-avc1-750k.cmfv \ tears-of-steel-avc1-1000k.cmfv \ tears-of-steel-avc1-1500k.cmfv

Testing playback¶

As we used keys obtained from the Widevine test server we can use the test license server to get a decryption license.

To test playback just upload the files to an https webserver, as this is a requirement for most DRM systems.

As an example, we have added the packaged assets to our demo site:

The SAMPLE-AES encrypted HLS can be tested in the Safari or iOS native players.

Widevine DRM can be tested in Chrome or Firefox:

Sours: https://docs.unified-streaming.com/documentation/package/multi-format-drm.html

DRM Versus Encrypted HLS: Which One Should You Use?

If you are in the business of delivering video via streaming or as a download, you’re certainly thinking about content protection. But how much content protection do you really need and what type of content protection works best? And more importantly, how much should you pay for it?

DRM (Digital Rights Management) and Encrypted HLS are the most commonly chosen content protection technologies used today. Both approaches have a strong track record in securing proprietary content. But there is growing interest by studios and other conventional DRM users in Encrypted HLS. So what’s driving this interest?

To start, it helps to understand how each method protects content. When you stream, the content isn’t delivered as one piece, it’s broken down into smaller bits and gets put back together when it reaches the screen. So while video content is delivered to the user’s client, it is unplayable without a decryption key. Content protected by DRM is made playable on a specific device — so that the content is encrypted and only viewable when the device receives its “unlock” code. In this manner, content can only be sent to one device per download, and therefore is not replicable.

Streamed media protected by Encrypted HLS isn’t replicable since it won’t “reassemble” well enough to be copied at a bit rate of 720p or below. (Although 720p is considered high definition, due to the nature of adaptive bit rate streaming, it is not suitable for reproduction and use elsewhere.) As long as content is not delivered over 720p, Encrypted HLS is as good as DRM.

Content owners/providers who are more focused on streaming media are probably more likely to have an interest in Encrypted HLS. This makes sense as Encrypted HLS is simpler and less expensive to deliver, manage and support. Delivery costs are lower since Encrypted HLS uses one format for all devices, as opposed to needing multiple device-specific formats, as one does with DRM. Encrypted HLS is easier to manage internally because there is no need to maintain a complex license delivery infrastructure in order to support multiple formats, as there is with DRM. Some also argue that it’s easier to reach a broader audience with Encrypted HLS, since a DRM strategy requires supporting multiple formats to reach the same audience (think streaming to every type of mobile device vs. needing an encryption key for each specific type of mobile device).

Then, there is the question of customer service calls, which we all know drive up costs. With DRM, when a customer cannot access their content, it takes extensive troubleshooting on the part of the provider to resolve the issue due to the complexity of the content being matched via encryption key to the device. With Encrypted HLS, consumers seamlessly access content they’ve paid for, resulting in lower customer service costs.

Beyond the operational and costs benefits of Encrypted HLS, the rising popularity of streaming to mobile devices is also a driving factor. Encrypted HLS reaches broader audiences more easily, and on a wider range of devices — all key benefits for the content owners targeting mobile users. And Encrypted HLS provides content protection that’s equal to DRM for content delivered up to 720p, another good fit for mobile users. If your end goal is to make your streaming content more widely available at a lower cost, then you might want to choose Encrypted HLS. That’s what RLJ Entertainment has been doing for their premium content service, Acorn TV.

Titus Bicknell, CDO & EVP of Operations for RLJ Entertainment recently told me that his role in the organization is to reduce friction in content consumption. Obviously, he needs to protect the IP holder, but also needs to ensure that his customers who have paid for the service can watch all of the content they want to. And Encrypted HLS has been a really strategic development for their product. Studios already agree to use Encrypted HLS with an important caveat: content must be delivered at 720p, not 1080p. RLJ Entertainment has moved all three of its channels from DRM protection to Encrypted HLS, citing the following benefits to their organization:

  • Better reflects consumer behavior. When consumers stream a movie or video, it’s usually with the intent to watch it immediately. The goal of providing seamless access to content at the highest possible speed and quality is more easily achieved with Encrypted HLS than DRM. As Mr. Bicknell explains, “The consumer’s investment in the content is more likely to be worthwhile because the technical barriers are lower.”
  • Wider distribution at a lower cost. Content owners can roll out a player that supports Encrypted HLS in any location where their content is consumed, with no need to pay a separate DRM licensing fee, an unlock fee, or hold transcoded renditions in both locked and unlocked formats for different platforms. Managed storage cost is also lowered because content owners are storing fewer renditions.
  • Easier on the organization. According to RLJ Entertainment, Encrypted HLS is easier to maintain, and easier on its customer service team, as its reps are no longer dealing with the 5% of people who are blocked from watching the content because the DRM doesn’t work.

“We’re in a business where the churn rate is critical to longevity, as well as our ability to license more interesting and better content for our customers. If you’re losing 1% per month because DRM is getting in the way of your customers watching content that they’re allowed to watch, that just decimates your business,” said Mr. Bicknell.

A recent Brightcove whitepaper also takes on this topic, entitled “Encrypted HLS vs. DRM: What’s Your Strategy for Protecting Your Digitally Distributed Copyright Content?” and explores the use cases for both Encrypted HLS and DRM.

What are your thoughts on Encrypted HLS? Are you sticking with DRM or moving away from it? I’d be interested in knowing your thoughts if you’d take this brief survey below.

Related

Filed in Consumer Content, Media & Entertainment, Video Formats/Platforms | Permalink | Comments (0)

Sours: https://www.streamingmediablog.com/2016/05/drm-versus-encrypted-hls.html
  1. Android charge limit without root
  2. Cap off water line
  3. Westinghouse tv old models

Radiant Media Player

DASH and HLS DRM

Supported DRM

Radiant Media Player supports the following DRM with DASH and/or HLS streaming. Our implementation relies on DRM features provided by Shaka Player.

Our DRM implementation relies on Encrypted Media Extensions (EME) support in the browser/WebView. Complementary to EME support a browser/WebView must have a compatible Content Decryption Module (CDM) to decrypt the DRM content.

To reach all devices we support you are going to need to use a combination of multiple DRMs. The player will automatically pick the correct DRM for the targeted environment. A popular approach is to use DASH with a combo of Widevine and PlayReady to reach desktop, smart TVs and Android, while also using Apple FairPlay HLS to reach Apple devices.

The below article explains how to use DASH & HLS with Widevine/PlayReady/Clear Key DRM. Documentation for Apple FairPlay Streaming can be found here.

Supported browsers/WebView for DRM

  • Browsers
    • Widevine
      • Chrome and Opera for Android 5+
      • Chrome, Firefox and Opera for Windows 7+, macOS 10.11+ and Linux
      • MS Edge 79+ for Windows 7+
      • Chrome for ChromeOS
    • PlayReady
    • FairPlay
      • Safari on iOS 12+ and iPadOS 13+
      • Safari for macOS 10.11+
  • Android & iOS mobile apps (Cordova/Ionic/WebView)
    • Widevine: Android 7+
    • FairPlay: WKWebView for iOS 13+ and iPadOS 13+
  • OTT apps
    • Widevine
      • Samsung Smart TV apps (Tizen 3+)
      • Desktop apps with Electron 6+
      • Android TV 8+
      • Google Cast receiver application
    • PlayReady
      • Xbox One+, Xbox Series S, Xbox Series X

In order to provide decent device coverage you are likely to have to use a multi-DRM approach. Combining Widevine, PlayReady and Apple FairPlay DRM is a common standard in the industry.

As an alternative to FairPlay Streaming one may use HLSe (AES-128/SAMPLE-AES encrypted HLS) as a fallback for iOS/macOS Safari, however it should be noted that HLSe provides a lesser level of security than FairPlay Streaming and may not meet studio requirements. See here for an example using DASH DRM and HLSe as a fallback.

Player configuration

General consideration

You may go through our MPEG-DASH streaming docs for a better understanding of MPEG-DASH streaming options with Radiant Media Player in this configuration.

To play DRM-protected content with MPEG-DASH, the player only needs to know 2 things: the URL of the DRM license server and what options are required to fetch and validate the license. Below you will also find various configuration options to support custom & advanced DRM use-cases.

Choosing a Key System

Radiant Media Player is key-system-agnostic, meaning it does not prefer any key systems over any others. We use EME to ask the browser what it supports, and make no assumptions. If the browser supports multiple key systems, the first supported key system in the MPEG-DASH manifest is used. The interoperable encryption standard that DRM vendors are implementing is called Common Encryption (CENC). Some MPEG-DASH manifests don't specify any particular key system at all, but instead state that any CENC system will do:

<ContentProtection schemeIdUri="urn:mpeg:dash:mp4protection:2011" value="cenc"/>

If this is the only <ContentProtection> element in the manifest, Radiant Media Player will try all key systems it knows. If the browser supports it and you configured a license server URL for it, we'll use it.

Player settings

This is where we feed the player the license server URL and other DRM-related options. The object supports 3 properties:

This is where license server URLs are passed to the player. Example for a combination of Widevine, PlayReady & Clear Key license servers:

shakaDrm: { servers: { 'com.widevine.alpha': 'https://foo.bar/drm/widevine', 'com.microsoft.playready': 'https://foo.bar/drm/playready', 'org.w3.clearkey': 'http://foo.bar/drm/clearkey' } }

The EME specification requires browsers to support a common key system called "Clear Key". Clear Key uses unencrypted keys to decrypt CENC content, and can be useful for diagnosing problems and testing integrations. To configure Clear Key, use the configuration field and provide a map of key IDs to content keys (both in HEX format). Example:

shakaDrm: { clearKeys: { 'deadbeefdeadbeefdeadbeefdeadbeef': '18675309186753091867530918675309', '02030507011013017019023029031037': '03050701302303204201080425098033' } }

We have several advanced options available to give you access to the full EME configuration. The configuration field is an object mapping key system IDs to their advanced settings. For example, to require hardware security in Widevine:

shakaDrm: { servers: { 'com.widevine.alpha': 'https://foo.bar/drm/widevine' }, advanced: { 'com.widevine.alpha': { 'videoRobustness': 'HW_SECURE_ALL', 'audioRobustness': 'HW_SECURE_ALL' } } }

Refer to this Google documentation page for a list of supported properties in the object.

About robustness levels (Widevine)

The robustness level key-system-specific string specifies a required security level for video/audio. By default it is set to '', which means that no specific robustness required, and this is the less secure approach. Content owners generally require a specific robustness level in order to allow a 3rd-party to distribute their content. For Widevine those robustness levels are (a lower level means better security):

  • : Widevine Device Security Level 3
  • : Widevine Device Security Level 3
  • : Widevine Device Security Level 2
  • : Widevine Device Security Level 1
  • : Widevine Device Security Level 1

About robustness levels (PlayReady)

For PlayReady those robustness levels are (a higher value means better security):

By default key system ignores given robustness and stays at a 2000 decryption level.

The introduction of key system allows for 3000 robustness (hardware DRM) - below is an example on how to use this robustness level with PlayReady:

var src = { dash: 'https://your-dash-url.mpd' }; var settings = { licenseKey: 'your-license-key', src: src, width: 640, height: 360, // We map urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95 and// urn:uuid:79f0049a-4098-8642-ab92-e65be0885f95 (this is a legacy value)// that are used for PlayReady// to the new com.microsoft.playready.recommandation key system shakaKeySystemsByURI: { 'urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95': 'com.microsoft.playready.recommendation', 'urn:uuid:79f0049a-4098-8642-ab92-e65be0885f95': 'com.microsoft.playready.recommendation' }, shakaDrm: { servers: { 'com.microsoft.playready.recommendation': 'https://your-playready-drm-server/rightsmanager.asmx?cfg=(persist:false,sl:3000)' }, advanced: { 'com.microsoft.playready.recommendation': { 'videoRobustness': '3000', 'sessionType': 'temporary' // if you want persistent license with PlayReady 3000 robustness//'sessionType': 'persistent-license' } } }, skin: 's1' }; var elementID = 'rmpPlayer'; var rmp = new RadiantMP(elementID); rmp.init(settings);

Player code example

Follows a player code example with DASH Widevine DRM (works on latest Chrome, Firefox).

<!-- Include Radiant Media Player - here we use the optimised build for Shaka player --> <script src="https://cdn.radiantmediatechs.com/rmp/6.4.12/js/rmp-shaka.min.js"></script> <!-- Player container element --> <div id="rmpPlayer"></div> <!-- Set up player configuration options --> <script> var src = { dash: 'https://storage.googleapis.com/shaka-demo-assets/angel-one-widevine/dash.mpd' }; var settings = { licenseKey: 'your-license-key', src: src, width: 640, height: 360, contentMetadata: { poster: [ 'https://your-poster-url.jpg' ] }, // passing DRM settings shakaDrm: { servers: { 'com.widevine.alpha': 'https://cwip-shaka-proxy.appspot.com/no_auth' } } }; var elementID = 'rmpPlayer'; var rmp = new RadiantMP(elementID); rmp.init(settings); </script>

Now an example with fMP4 HLS Widevine DRM (works on latest Chrome, Firefox).

<!-- Include Radiant Media Player - here we use the optimised build for Shaka player --> <script src="https://cdn.radiantmediatechs.com/rmp/6.4.12/js/rmp-shaka.min.js"></script> <!-- Player container element --> <div id="rmpPlayer"></div> <!-- Set up player configuration options --> <script> var src = { hls: 'https://storage.googleapis.com/shaka-demo-assets/angel-one-widevine-hls/hls.m3u8' }; var settings = { licenseKey: 'your-license-key', src: src, width: 640, height: 360, contentMetadata: { poster: [ 'https://your-poster-url.jpg' ] }, hlsEngine: 'shakaplayer', // passing DRM settings shakaDrm: { servers: { 'com.widevine.alpha': 'https://cwip-shaka-proxy.appspot.com/no_auth' } } }; var elementID = 'rmpPlayer'; var rmp = new RadiantMP(elementID); rmp.init(settings); </script>

License server authentication

Your license server may require some form of authentication so that it only delivers licenses to paying users. In this section we're going to use various license server endpoints that require various forms of authentication. If you need live example to test your set up you can refer to this Google documentation page.

We provide support for 3 authentication modes: header authentication, parameter authentication & cookie authentication

Authentication is provided through the player setting. You can refer to our MPEG-DASH docs for more information as this setting may also be used outside DRM context.

Header authentication

In this case your license server requires a specific header value to deliver a license. If you try to use it without setting the authentication header, you will see Error code 6007 in the player logs, which means LICENSE_REQUEST_FAILED. The JavaScript console will show you a failed HTTP request with HTTP status code 401 (Unauthorized), and playback will hang when you get to the encrypted part of the stream.

To provide header authentication we will use the player setting as follows:

shakaRequestConfiguration: { license: { headers: { 'CWIP-Auth-Header': 'VGhpc0lzQVRlc3QK' } } }

Full player example - this example is provided for Widevine DRM - see this example here

<!-- Include Radiant Media Player - here we use the optimised build for Shaka player --> <script src="https://cdn.radiantmediatechs.com/rmp/6.4.12/js/rmp-shaka.min.js"></script> <!-- Player container element --> <div id="rmpPlayer"></div> <!-- Set up player configuration options --> <script> var src = { dash: 'https://storage.googleapis.com/shaka-demo-assets/sintel-widevine/dash.mpd' }; var settings = { licenseKey: 'your-license-key', src: src, width: 640, height: 360, contentMetadata: { poster: [ 'https://your-poster-url.jpg' ] }, // passing DRM settings shakaDrm: { servers: { 'com.widevine.alpha': 'https://cwip-shaka-proxy.appspot.com/header_auth' } }, shakaRequestConfiguration: { license: { headers: { 'CWIP-Auth-Header': 'VGhpc0lzQVRlc3QK' } } } }; var elementID = 'rmpPlayer'; var rmp = new RadiantMP(elementID); rmp.init(settings); </script>
Parameter authentication

Now, we'll try authentication using URL parameters. In this case the license server endpoint requires a specific URL parameter to deliver a license. If you try to use it without setting the parameter, you will see Error code 6007 (LICENSE_REQUEST_FAILED) in player logs just as before with header authentication.

Again to provide parameter authentication we will use the player setting as follows:

shakaRequestConfiguration: { license: { parameters: '?CWIP-Auth-Param=VGhpc0lzQVRlc3QK' } }

Full player example - this example is provided for Widevine DRM - test in Chrome:

<!-- Include Radiant Media Player - here we use the optimised build for Shaka player --> <script src="https://cdn.radiantmediatechs.com/rmp/6.4.12/js/rmp-shaka.min.js"></script> <!-- Player container element --> <div id="rmpPlayer"></div> <!-- Set up player configuration options --> <script> var src = { dash: 'https://storage.googleapis.com/shaka-demo-assets/sintel-widevine/dash.mpd' }; var settings = { licenseKey: 'your-license-key', src: src, width: 640, height: 360, contentMetadata: { poster: [ 'https://your-poster-url.jpg' ] }, // passing DRM settings shakaDrm: { servers: { 'com.widevine.alpha': 'https://cwip-shaka-proxy.appspot.com/param_auth' } }, shakaRequestConfiguration: { license: { parameters: '?CWIP-Auth-Param=VGhpc0lzQVRlc3QK' } } }; var elementID = 'rmpPlayer'; var rmp = new RadiantMP(elementID); rmp.init(settings); </script>
Cookie authentication

Now, let's try using cookies for authentication. In this case the license server endpoint requires a specific cookie to deliver a license. If you try to use it without setting the parameter, you will see Error code 6007 (LICENSE_REQUEST_FAILED) in player logs. Cookies are set by a server to be returned to that server, and are not sent by the JavaScript application. So to set the required cookie value for this test example, point your browser to the server's set_cookie page. Cookies are considered "credentials" by the browser's XmlHttpRequest API, and credentials may not be sent cross-origin unless explicitly requested by the application AND explicitly allowed by the destination server. Our cookie_auth license server endpoint sends back headers that allow credentialed requests, so we also need to tell the player to send credentials cross-site.

Again to provide cookie authentication we will use the player setting as follows:

shakaRequestConfiguration: { license: { credentials: true } }

Full player example - this example is provided for Widevine DRM - test in Chrome:

<!-- Include Radiant Media Player - here we use the optimised build for Shaka player --> <script src="https://cdn.radiantmediatechs.com/rmp/6.4.12/js/rmp-shaka.min.js"></script> <!-- Player container element --> <div id="rmpPlayer"></div> <!-- Set up player configuration options --> <script> var src = { dash: 'https://storage.googleapis.com/shaka-demo-assets/sintel-widevine/dash.mpd' }; var settings = { licenseKey: 'your-license-key', src: src, width: 640, height: 360, contentMetadata: { poster: [ 'https://your-poster-url.jpg' ] }, // passing DRM settings shakaDrm: { servers: { 'com.widevine.alpha': 'https://cwip-shaka-proxy.appspot.com/cookie_auth' } }, shakaRequestConfiguration: { license: { credentials: true } } }; var elementID = 'rmpPlayer'; var rmp = new RadiantMP(elementID); rmp.init(settings); </script>
Asynchronous credentials

In some scenarios, you may not know the credentials right away. An additional request to get those credentials may be needed before you attach them to the request Radiant Media Player wants to make. This can be done through the and player settings. Refer to this Shaka player docs for more information. Following is a player code example for using asynchronous credentials and Radiant Media Player:

<!-- Include Radiant Media Player - here we use the optimised build for Shaka player --> <script src="https://cdn.radiantmediatechs.com/rmp/6.4.12/js/rmp-shaka.min.js"></script> <!-- Player container element --> <div id="rmpPlayer"></div> <!-- Set up player configuration options --> <script> var licenseServer = 'https://cwip-shaka-proxy.appspot.com/header_auth'; var authTokenServer = 'https://cwip-shaka-proxy.appspot.com/get_auth_token'; var authToken = null; var elementID = 'rmpPlayer'; var rmp = new RadiantMP(elementID); var shakaCustomRequestFilter = function (type, request) { console.log('shakaCustomRequestFilter callback'); // Only add headers to license requests: if (type != shaka.net.NetworkingEngine.RequestType.LICENSE) return; // If we already know the token, attach it right away: if (authToken) { console.log('Have auth token, attaching to license request.'); request.headers['CWIP-Auth-Header'] = authToken; return; } console.log('Need auth token.'); // Start an asynchronous request, and return a Promise chain based on that. var authRequest = { uris: [authTokenServer], method: 'POST', }; var requestType = shaka.net.NetworkingEngine.RequestType.APP; return rmp.shakaPlayer.getNetworkingEngine().request(requestType, authRequest).then( function (response) { // This endpoint responds with the value we should use in the header. authToken = shaka.util.StringUtils.fromUTF8(response.data); console.log('Received auth token', authToken); request.headers['CWIP-Auth-Header'] = authToken; console.log('License request can now continue.'); }); }; var src = { dash: 'https://storage.googleapis.com/shaka-demo-assets/sintel-widevine/dash.mpd' }; var settings = { licenseKey: 'your-license-key', src: src, // passing DRM settings shakaDrm: { servers: { 'com.widevine.alpha': licenseServer } }, shakaCustomRequestFilter: shakaCustomRequestFilter, contentMetadata: { poster: [ 'https://your-poster-url.jpg' ] } }; rmp.init(settings); </script>

DASH DRM with AES-128/SAMPLE-AES HLS fallback

When using a combined Widevine/PlayReady DRM approach with DASH streaming modern browser support should be fairly good. However on iOS or macOS Safari where DRM Widevine/PlayReady are not supported you can use HLSe (AES-128/SAMPLE-AES encrypted HLS) as a fallback. On macOS and iOS Safari you may also consider using Apple FairPlay DRM.

Player code example:

<!-- Include Radiant Media Player - here we use the optimised build for Shaka player --> <script src="https://cdn.radiantmediatechs.com/rmp/6.4.12/js/rmp-shaka.min.js"></script> <!-- Player container element --> <div id="rmpPlayer"></div> <!-- Set up player configuration options --> <script> var src = { dash: 'https://media.axprod.net/TestVectors/v7-MultiDRM-SingleKey/Manifest.mpd', // here is our AES-128 HLS fallback hls: 'https://www.radiantmediaplayer.com/media/rmp-segment/bbb-abr-aes/playlist.m3u8' }; var settings = { licenseKey: 'your-license-key', src: src, width: 640, height: 360, contentMetadata: { poster: [ 'https://your-poster-url.jpg' ] }, dashFirst: true, hlsEngine: 'hlsjs', // passing DRM settings shakaDrm: { servers: { 'com.widevine.alpha': 'https://drm-widevine-licensing.axtest.net/AcquireLicense', 'com.microsoft.playready': 'https://drm-playready-licensing.axtest.net/AcquireLicense' } }, shakaRequestConfiguration: { license: { headers: { 'X-AxDRM-Message': 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2ZXJzaW9uIjoxLCJjb21fa2V5X2lkIjoiYjMzNjRlYjUtNTFmNi00YWUzLThjOTgtMzNjZWQ1ZTMxYzc4IiwibWVzc2FnZSI6eyJ0eXBlIjoiZW50aXRsZW1lbnRfbWVzc2FnZSIsImtleXMiOlt7ImlkIjoiOWViNDA1MGQtZTQ0Yi00ODAyLTkzMmUtMjdkNzUwODNlMjY2IiwiZW5jcnlwdGVkX2tleSI6ImxLM09qSExZVzI0Y3Iya3RSNzRmbnc9PSJ9XX19.4lWwW46k-oWcah8oN18LPj5OLS5ZU-_AQv7fe0JhNjA' } } } }; var elementID = 'rmpPlayer'; var rmp = new RadiantMP(elementID); rmp.init(settings); </script>

Offline DRM and persistent license support

The player automatically downloads and stores persistent licenses when available. Persistent licenses allow for offline playback of DRM protected content without the need for an Internet connection to access content.

Persistent licenses are supported in:

  • Chrome 64+ for Android 6+
  • Chrome 64+ for macOS 10.11+
  • Chrome 64+ for Windows 10+
  • Chrome 64+ for Chromebooks (ChromeOS)
  • WebView 64+ for Android 6+ (mobile apps for Android including those built with Cordova/Ionic)

Persistent licenses could work in other environments like Opera 62+, MS Edge 79+ or Samsung Internet 13+ but those environments are not officially supported.

The following environments are not supported for DRM persistent licenses: Safari (all platforms), Firefox (all platforms).

Note that you will need to use DASH streaming to support persistent licenses (PlayReady or Widevine DRM).

For other platforms, where storage of persistent licenses is not available you will get offline storage of protected content on all DRM-enabled browsers, at the cost of needing a network connection at playback time to retrieve licenses.

Changing player source with DRM

If you are using the API method to change player source with DRM content you could likely want to update the player with new DRM information. This can be done by using the following API methods:

Returns the current custom request filter for Shaka player used by Radiant Media Player.

Takes shakaCustomRequestFilter as an input to update the current custom request filter for Shaka player used by Radiant Media Player. This should be used just before using API method.

Returns the current request configuration for Shaka player used by Radiant Media Player.

Takes shakaRequestConfiguration as an input to update the current request configuration for Shaka player used by Radiant Media Player. This should be used just before using API method.

Returns the current DRM configuration for Shaka player used by Radiant Media Player.

Takes shakaDrm as an input to update the current DRM configuration for Shaka player used by Radiant Media Player. This should be used just before using API method.

Usage example:

<!-- Include Radiant Media Player - here we use the optimised build for Shaka player --> <script src="https://cdn.radiantmediatechs.com/rmp/6.4.12/js/rmp-shaka.min.js"></script> <!-- Player container element --> <div id="rmpPlayer"></div> <!-- Set up player configuration options --> <script> var src = { dash: 'https://storage.googleapis.com/shaka-demo-assets/angel-one-widevine/dash.mpd' }; var settings = { licenseKey: 'your-license-key', src: src, width: 640, height: 360, autoplay: true, // passing DRM settings shakaDrm: { servers: { 'com.widevine.alpha': 'https://cwip-shaka-proxy.appspot.com/no_auth' } } }; var elementID = 'rmpPlayer'; var rmp = new RadiantMP(elementID); rmp.init(settings); // this setTimeout function just emulate a case where setSrc is called with new DRM information setTimeout(function () { window.console.log(rmp.getShakaDrm()); rmp.setShakaRequestConfiguration({ license: { headers: { 'X-AxDRM-Message': 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2ZXJzaW9uIjoxLCJjb21fa2V5X2lkIjoiYjMzNjRlYjUtNTFmNi00YWUzLThjOTgtMzNjZWQ1ZTMxYzc4IiwibWVzc2FnZSI6eyJ0eXBlIjoiZW50aXRsZW1lbnRfbWVzc2FnZSIsImtleXMiOlt7ImlkIjoiOWViNDA1MGQtZTQ0Yi00ODAyLTkzMmUtMjdkNzUwODNlMjY2IiwiZW5jcnlwdGVkX2tleSI6ImxLM09qSExZVzI0Y3Iya3RSNzRmbnc9PSJ9XX19.4lWwW46k-oWcah8oN18LPj5OLS5ZU-_AQv7fe0JhNjA' } } }); rmp.setShakaDrm({ servers: { 'com.widevine.alpha': 'https://drm-widevine-licensing.axtest.net/AcquireLicense', } } ); rmp.setSrc({ dash: 'https://media.axprod.net/TestVectors/v7-MultiDRM-SingleKey/Manifest.mpd' }); }, 15000); </script>

Supported DRM service providers

Radiant Media Player should work with any standard compliant DRM service providers that can encrypt media content with Widevine and/or PlayReady and/or FairPlay DRM. Below are names of DRM services that our customers have successfully used with Radiant Media Player:

Based on the solution your DRM service provider offer you may also need a solution to package your content for DASH or HLS. Wowza Streaming Engine supports on-the-fly DASH CENC encryption for on demand and live content via the PlayReady and Widevine DRM systems.

Sours: https://www.radiantmediaplayer.com/docs/latest/dash-drm-documentation.html
How to Decrypt HLS Content

HLS with Transport Streams (TS)¶

USP supports adding AES encryption. The encryption is applied on-the-fly, so there is no preprocessing involved.

The options for enabling encryptions are stored in the server manifest file.

For HLS AES encryption a CEK (Content Encryption Key) and a license acquisition URL (the location where the player retrieves the key) are needed.

Demo streams can be found in the Unified Streaming Demo.

Adding AES-128 Encryption¶

Next is creating a server manifest file with enabled encryption. You need to provide the following options:

--hls.key¶

The key id (KID) and content encryption key (CEK) are passed with the option where KID and CEK are separated by a colon, e.g.

As no KID is used for AES-128, this can be left empty. The CEK is a (random) 128 bit value and must be coded in hex (base16).

--hls.license_server_url¶

The URL used by the player to retrieve the key.

Content Key¶

You can use openssl for generating a random key:

#!/bin/bash openssl rand 16 > video.key

The file video.key holds the encryption key that will be requested by the player. If openssl returns "unable to write 'random state'", remove then try once more.

Example¶

The following command creates a server manifest file with the key information embedded:

#!/bin/bash mp4split -o video.ism \ --hls.key=:`cat video.key | hexdump -e '16/1 "%02x"'`\ --hls.license_server_url=https://license-server/video.key \ video.ismv

The generated server manifest file (video.ism) now holds the key information. When a client requests a .m3u8 playlist the webserver module will automatically insert the proper tag and requests for the MPEG-TS fragments are encrypted on-the-fly.

An example .m3u8 playlist:

#EXTM3U#EXT-X-VERSION:1#EXT-X-MEDIA-SEQUENCE:0#EXT-X-KEY:METHOD=AES-128,URI="https://license-server/video.key"#EXTINF:4, no desc video-audio=65000-video=236000-0.ts

The following command creates a server manifest file with the key information embedded:

#!/bin/bash mp4split -o video.ism \ --hls.key=:000102030405060708090a0b0c0d0e0f \ --hls.license_server_url=https://www.example.com/oceans.key \ video.ismv

Download¶

Please download the sample script which creates the various server manifest as discussed above. The sample content is Tears of Steel.

Adding SAMPLE-AES Encryption¶

For SAMPLE-AES encryption the setup is similar. Please note that this is for on-the-fly encryption. For file based encryption see Packaging HTTP Live Streaming (HLS) with TS.

First we create a 128-bit CEK (Content Encryption Key) and optional 128-bit IV (Initialization Vector). These are just files with 16 random bytes. You could use for example 'openssl' to create the key.

#!/bin/bash openssl rand 16 > content.key openssl rand 16 > init_vector.key

The command-lines for creating the server manifest is similar to the above, except that we need to use different options.

--hls.key¶

The key id (KID) and content encryption key (CEK) are passed with the option where KID and CEK are separated by a colon, e.g.

As no KID is used for AES-128, this can be left empty. The CEK is a (random) 128 bit value and must be coded in hex (base16).

--hls.key_iv¶

The initialization vector (automatically generated if missing).

--hls.license_server_url¶

The URL used by the player to retrieve the key.

--hls.playout¶

The string identifier 'sample_aes'.

Example¶

#!/bin/bashCEK=`cat content.key | hexdump -e '16/1 "%02x"'`KIV=`cat init_vector.key | hexdump -e '16/1 "%02x"'`# URL that resolves to content.keyLA_URL=https://license-server/content.key mp4split -o example.ism \ --hls.key=:${CEK}\ --hls.key_iv=${KIV}\ --hls.license_server_url=${LA_URL}\ --hls.playout=sample_aes \ oceans-64k.ismv oceans-250k.ismv

Adding China DRM¶

China DRM is specified with the option, where the appropriate signaling will be present in the media playlists.

Example¶

#!/bin/bashCEK=CONTENT_ENCRYPTION_KEY_IN_HEX IV=KEY_IV_IN_HEX LA_URL=http://LICENSE_SERVER_URL mp4split -o video.ism \ --hls.key=:${CEK}\ --hls.key_iv=${IV}\ --hls.license_server_url=${LA_URL}\ --hls.playout=aes \ --hls.key_format="chinadrm"\ video-500k.ismv video-750k.ismv video-1500k.ismv

Adding FairPlay DRM¶

This is similar to the SAMPLE-AES described in the previous paragraph with two additional tags added to the tag.

The is set to "com.apple.streamingkeydelivery" and the is set to "1".

To enable the additional signaling, you have to change the option from 'sample_aes' to 'sample_aes_streamingkeydelivery'.

Note that, while sample_aes only requires an iOS device, the client application is required to be developed using Apple's FairPlay SDK for it to be able to work with sample_aes_streamingkeydelivery.

--hls.playout¶

The string identifier .

Special care needs to be taken with the content_key/key_iv, this needs to 32 bytes.

It can be created like this:

#!/bin/bash openssl rand 32 > presentation.key

Here content_key is the first 16 and key_iv the second 16. Pass these separately as and .

Alternatively you can create two 16 byte values and cat them together in a single file.

The player will fetch it using the 'fairplay sdk'.

Note

Dolby Digital Plus, also known as Enhanced AC-3 or EC-3 audio streams are supported as well. See HLS Sample-AES Audio Formats for further reference.

Adding Marlin DRM¶

USP supports adding Marlin protection to HLS presentations using AES. The options for enabling encrypted playout are stored in the server manifest file. For Marlin HLS AES encryption the KID and CEK are specified as Adding Marlin DRM. Additionally, Marlin playout allows a content id attribute to be specified as a query parameter of the license server URL.

Options for Marlin¶

You need to provide the following options:

--hls.playout=marlin¶

Enable Marlin AES encryption

--marlin.key¶

The KID and CEK are passed with the option where KID and CEK are separated by a colon, e.g.

Note that both KID and CEK must be coded in hex (base16).

--marlin.license_server_url¶

The license server URL, where is stripped from the URL and instead passed as a separate attribute in

Example¶

The following command creates a server manifest file for HLS playout with AES Marlin DRM:

mp4split -o video.ism \ --hls.playout=marlin \ --marlin.key=b366360da82e9c6e0b0984002a362cf2:a0a1a2a3a4a5a6a7a8a9aaabacadaeaf \ --marlin.license_server_url=urn:marlin-drm?CID=content1234 \ video.mp4

The generated playlists will contain a line like:

#EXT-X-KEY:METHOD=AES-128,URI="urn:marlin-drm",CID="content1234"

Clients and Playout¶

For playout you need a Marlin capable player, for instance Intertrust's Wasabi Marlin Client SDK for more information.

Adding Primetime DRM¶

There are two variants for Adobe Primetime with HLS, AES-128 and SAMPLE-AES. By default, AES-128 is used unless a different hls playout type is specified. The following example shows the preparation of a server manifest file for Adobe Primetime SAMPLE-AES.

#!/bin/bashCEK=CONTENT_ENCRYPTION_KEY_IN_HEX IV=KEY_IV_IN_HEX LA_URL=http://LICENSE_SERVER_URL DRM_DATA=BASE64_DRM_DATA mp4split -o video.ism \ --hls.key=:${CEK}\ --hls.key_iv=${IV}\ --hls.license_server_url=${LA_URL}\ --hls.playout=faxs_sample_aes \ --hls.inline_drm \ --hds.drm_specific_data=${DRM_DATA}\ video-500k.ismv video-750k.ismv video-1500k.ismv
Sours: https://docs.unified-streaming.com/documentation/drm/hls.html

Hls drm

VdoCipher

What is HLS Streaming?

HLS Streaming (HTTP Live Streaming) is a streaming protocol used for video content across desktop and mobile devices. HLS is developed by Apple, which forms the biggest use case for the streaming protocol. Beyond Apple, there is wide support for HLS streaming across Android devices and browsers. Indeed, HLS can be used as a streaming protocol for all major browsers, including Chrome and Firefox.

In HLS Encryption the video files are encrypted using a secure AES-128 algorithm. The AES 128 encryption is the only publicly available security algorithm that is used by the NSA for encrypting its top-secret classified information.

HLS streaming and HLS Encryption can be used for both the cases of live streaming and for Video on Demand streaming (VOD). Because video streaming is over HTTPS, there is no need for a streaming server, unlike RTMP, which requires its own streaming server.

HLS Streaming Protocol is not blocked by firewalls, unlike RTMP streaming protocol

How & Why Apple Developed HLS Streaming ?

Until about 2010, Flash was the most popular video streaming application. It was supported by all desktop browsers. Because Flash utilized the same runtime across all browsers, it meant that video streamers did not have to create separate workflows for different devices. DRM and encryption were also supported by Flash.

Flash was however plagued by security issues. Video playback on Flash was processor-intensive, which caused mobile batteries to drain very fast. For these reasons Apple did not support Flash in the iPhone and in iPad, instead including support for native HTML5 video playback.

Apple created its own specifications for video streaming, which could be used for both live streaming and for pre-recorded video streaming. Android OS followed suit by blocking flash playback from browsers on Android. From the introduction of the smartphone to the emergence of MPEG-DASH around 2015, Apple’s HLS streaming has been the most widely used protocol.

Because of Apple’s continued support for the protocol, encoding for HLS player is an integral element of any video streaming provider’s workflow.

How does HLS streaming work?

In plain vanilla HTML5 video streaming, only a single video file is available for streaming. The download of the complete video file is initiated every time the stream is played. Even if a viewer watches only 2 minutes of a 30-minute video, the full video would be downloaded, causing data wastage at both the server and the user end.

Streaming protocols remove this inefficiency in video streaming. Streaming protocols such as HLS effectively break down a video file into multiple chunks when streaming, and these video files are downloaded over HTTP in succession. HLS streaming uses the same workflow for both live and for on-demand content. The core idea in multi-bitrate streaming is that multiple renditions of each video, of varying resolution, are encoded. High-resolution videos are delivered to large screen devices having high network bandwidth, whereas lower resolution videos are encoded for mobile phones. Encoding for low resolutions also ensures continuous video streaming when the network connection speed drops.

Progressive streaming using HLS AES-128 Protocol

When the user decides to change video resolution, or when the network bandwidth changes, video streams can be manually (or automatically) switched. HLS video streams are encoded using the H.264 standard, which can be played across all devices. Each of the video copies is broken into multiple chunks having the .ts (transport stream) extension.

There is a main index file, called the manifest file (.m3u8 file format), associated with the video stream. The main manifest file contains links to the specific manifest files associated with each unique video stream. Each of these specific manifest files in its place directs the video stream to the correct URL for video playback when streams are switched. This ensures that stream switching is seamless. This process of a manifest file referring to the video stream is the same for both live video streaming and for on-demand video streaming. The only difference for live video is simply that the video files are being encoded in real-time.

Streaming over HTTP has many advantages over using a separate server. For example, firewalls that may be used to block ports used for RTMP are unlikely to affect video streaming over HTTP. No additional cost are required for streaming over an HTTP server.

Video Streaming through HLS protocol

What is HLS Encryption? Is HLS Encryption effectively secure against piracy?

HLS AES-128 encryption refers to video streams using HLS streaming protocol wherein the video files are encrypted using the AES-128 algorithms. The key exchange happens through the secure HTTPS protocol. If done in a rudimentary way the key for decryption can be seen from the network console by accessing the manifest file. A poor implementation of HLS encryption would result in plugins automatically finding the key and decrypting the HLS encrypted stream, rendering video security ineffective.

Basic HLS Encryption where the key is in the manifest file

There are however methods to strengthen the HLS Encrypted stream. The challenge is to make sure that the key is not exposed directly. These are the options for additional security in HLS Encryption:

  • Not including URL to decryption key in Manifest File

Implementations for this vary widely, and are quite difficult by themselves. This method for protecting HLS content may also cause compatibility issues on devices. If done properly however it is definitely a major improvement in video security.

  • Using authenticated cookies for HLS Encryption streaming

In this method, the browser of authorized users stores authentication cookies. These cookies are stored with a digital signature, to ensure that they are not tampered with. This ensures that only the authorised user (and not some external plugin) is seeking to fetch content. The following workflow is used for configuring authentication cookies for HLS encryption:

      1. Trusted signers are configured, who have permission to create authentication cookies. This configuration is done at the edge location (content delivery network)
      2. Application is developed to send set-cookie headers to authorized viewers
      3. Authorized users store name-value pairs in the cookie
      4. When user requests protected content, the browser adds the name-value pair in the cookie header to the request
      5. The CDN uses the public key to verify the digital signature in the name-value pair
      6. If the authentication cookie is verified, the CDN looks at the authentication cookie’s policy statement. The policy statement determines if the access request is valid. For example, the policy statement could include the beginning and end time for cookie validity.

Advanced HLS Encryption, using authentication cookies/ signed URLs
For further information on authentication cookies for content protection, you can have a look at Amazon Cloudfront’s documentation.

  • Signed URLs can be generated for authorized users

The following workflow is used for configuring signed URLs for HLS encryption:

      1. In the CDN trusted signers are created, who have permission to create signed URLs
      2. Develop an application to create signed URLs for protected content
      3. When user requests protected content by signed URLs, the application verifies if they have the authorization to access it
      4. If verified, the application creates a signed URL and sends it to the requesting user
      5. On accessing content through a signed URL, the CDN verifies that the URL has not been tampered with. This is done by using the Public Key to verify the digital signature of the URL
      6. If the signed URL is valid,
      7. The CDN uses the public key to verify the digital signature in the name-value pair
      8. If the signed URL is verified, the CDN looks at the signed URL’s policy statement. The policy statement determines if the access request is valid. For example, the policy statement could include the beginning and end times for the signed URL. For protecting content, this period of validity of URLs should be short – as little as a few minutes is optimal. For this you can create dynamic URLs, that change every few minutes.

For further information on signed URLs for content protection, you can have a look at Amazon Cloudfront’s documentation.

All these 3 steps make the video stream considerably immune to direct download through plugins. However, these methods are still breakable by already available codes and tech hacks.

How is DRM level security for HLS Encryption possible?

DRM requires that the key exchange and licensing mechanism is highly secure and is always out of reach of external tools and hackers. A DRM technology also has additional elements. It delivers a license file, which also specifies the usage rights of the viewer. Usage rights specify the conditions in which the video playback is allowed.
Implementation of these usage rights ensures that the signed key used for decryption can only be used for playback on the viewer’s device. The key would simply fail to decrypt the video stream if the video file is copied to any other device.

DRM adds complex layers of workflow for license management. This workflow includes:

  1. Specifying highly detailed usage rights such as-
    1. Limiting video playback on a device to only a fixed number of times
    2. Video access can expire after a period of days if the subscription is not renewed
    3. Limiting the device or screen on which the video can be played. For example usage rights can be used to restrict users to cast their video playback on an external device such as a Smart TV.
  2. The license database is also bound to the user’s device, which means that if shared the license and decryption key becomes redundant.
  3. Licenses are also signed with the digital signature, which means that they cannot tamper with either during transit over HTTP or when stored locally on the device.

Implementing DRM along with HLS streaming entails considerable modification of the HLS Encryption infrastructure.  At VdoCipher, we have been able to do that and provide a full-fledged proprietary + HLS DRM. We cannot technically say that we are streaming an HLS encrypted stream as it is highly modified. We use a combination of other technologies based on different platforms and are able to roll out a cross-device, cross-browser compatible DRM.

VdoCipher HLS Encrypted DRM Infrastructure Details

  1. Upload of Videos (All common formats are supported )
    The content can be uploaded through Dashboard or APIs. Upload from desktop, FTP, DropBox, Box, URL, Server all is supported.
  2. Encryption & Transcoding for DRM streaming
    Videos are converted into encrypted files, and multiple qualities & versions for ensuring delivery of quality content at all devices, browsers, and all connection speeds. The encrypted content is stored at our AWS S3 servers and raw videos are never exposed. We have set up our custom EC2 instances for the encoding pipeline, and the resultant files are hosted securely on AWS S3 servers.
  3. Encrypted Video Streaming (Modified HLS Encryption & Streaming)
    As discussed above the high-security key and license exchange mechanism supports the transfer of encrypted video data, ensuring HLS DRM level security. Dynamic URLs ensure that each playback is authenticated and the URL cannot be extracted outside the website or app for pirated playback. We use multiple top tier CDNs – Cloudfront, Akamai, Google CDN, Verizon to ensure smooth delivery of content all across the globe
  4. Decryption in Video Player & Watermarking
    There is a private communication between our API & the client website. This ensures that its not possible for hackers to decrypt our streams. The One Time encryption that we use is theoretically and practically hack-proof. The website embedding the video content requests a One-time password from the VdoCipher web server using the API. This OTP request is made only after the user is authenticated. The VdoCipher API returns the OTP, which is used to render the embed code. This embed code is valid for a single playback session only. Along with the key a usage policy is specified, ensuring that only a logged-in and authenticated user is allowed to playback the encrypted video. The video would simply fail to play if an external plugin or downloader is used to try to access the video file.We have timely modifications to our licensing and authentication mechanism to keep security updated.
  5. Watermarking -Video licensing and playback are combined to generate customisable viewer specific watermarks. The watermark can be IP address, Email ID  and User ID shown in customisable colour & transparency to identify a playback session by the viewer.
  6. Result – Progressive High Secure Streaming
    Through this 6-step Video Hosting, Encryption and Streaming process, VdoCipher is able to provide a progressive high security video streaming with future buffer possible. This is also different from RTMP which does not maintain any buffer and can be quite erratic as a result.


Demo Free Trial for HLS DRM Streaming

You can signup for a free full version trial at VdoCipher.

Online businesses also often require features over and beyond video security. VdoCipher fulfills all major requirements for enterprise video hosting. The complete set of features that VdoCipher offers for enterprise video hosting may be found here.

Also, do read our blog on react native video playback.


Signup for Free 30 Day Trial

Supercharge Your Business with Videos

At VdoCipher we maintain the strongest content protection for videos. We also work extremely hard to deliver the best viewer experience. We'd love to hear from you, and help boost your video streaming business.

Free 30-day trial

Filed Under: DRM, HLS, Market & technology analysis, TechnologyTagged With: HLS DRM, HLS Encryption, HLS player, HLS streaming

Sours: https://www.vdocipher.com/blog/2017/08/hls-streaming-hls-encryption-secure-hls-drm/
Webinar: Low-Latency Delivery — LL-HLS vs. WebRTC

What is the reccomended way to use HLS and DASH + DRM in a player?

The use of HLS vs DASH is typically dictated by the end device and client capabilities and rules.

iOS and Safari typically use HLS and FairPlay, Android, Firefox and Chrome use DASH and Widevine and Windows and Edge use DASH and PlayReady.

Note that Widevine and PlayReady can use the same DASH stream - CENC, Common Encryption standard, allows the same stream to include both Widevine and PlayReady DRM information.

At this time, Apple iOS devices must use HLS for content greater than 10 mins over a mobile network:

2.5.7 Video streaming content over a cellular network longer than 10 minutes must use HTTP Live Streaming and include a baseline 192 kbps HTTP Live stream.

(https://developer.apple.com/app-store/review/guidelines/)

For this reason streams served to Apple devices are usually HLS, while DASH is used for other devices.

CMAF greatly reduces the impact of this by allowing the same segmented media stream be used for both HLS and DASH, with just the 'index' or manifest files being specific to each protocol.

For encrypted content it is a bit more complicated. At this time, FairPlay uses a different AES encryption mode, AES CBC, than Widevine and PlayReady which use AES-CTR. This means you still need two copies of the media to serve encrypted content streams.

This is changing as Widevine and PlayReady now have announced support for AES-CBC as well as AES-CTR, but it will take some time for this to roll out to deployed devices.

Sours: https://stackoverflow.com/questions/61948356/what-is-the-reccomended-way-to-use-hls-and-dash-drm-in-a-player

You will also like:

And suddenly she gave up, I loosened the grip of her hands, turned to face me and did it in vain - I got a knee in the groin. How painful and insulting and stupid it turned out. She seemed to be able to sense this pain and evidently realized that she had outplayed too much. I crawled onto the sofa, she landed nearby.

SHE How I was torn from his hands, I realized that I could not just give up.



236 237 238 239 240