Digital Rights Management Complexities Untangled with Bitmovin & Vualto
•Télécharger en tant que PPT, PDF•
0 j'aime•98 vues
As part of Bitmovin's virtual event series, Security and Protection Week. Bitmovin came together with CDN and DRM provider, Vualto to breakdown the complexities of a DRM workflow. In the webinar we covered how OTT platforms can achieve more flexibility with their back-end policies and security levels with CBCS encryption methods. In addition, the webinar demonstrated how to generate a CMAF stream using VUDRM. To view the full webinar and demonstration on demand, fill out the form on the following page: https://bit.ly/35kUKjt
Recommandé
Recommandé
Contenu connexe
Plus de Bitmovin Inc
Plus de Bitmovin Inc (20)
Dernier
Dernier (20)
Digital Rights Management Complexities Untangled with Bitmovin & Vualto
- 2. OTT VIDEO ORCHESTRATION & DELIVERY Live Streaming VOD Streaming LIVE2VOD CLIP2VU Dynamic Playout Profiling Dynamic Scaling Multi-DRM Support Evolved Infrastructure No need for re-encryption Scalable & Resilient Multi-Player Integration 24/7 NOC Monitoring & Support PREMIUM MULTI-AGNOSTIC DRM CONTENT PROTECTION
- 3. BITMOVIN and VUDRM Audio Track Video Track Source File Audio Codec Config Video Codec Config Audio Stream Video Stream Audio Muxing Video Muxing Packaging Format Packaging Format Encrypted Audio Muxing DRM Config DRM Config CPIX doc containing encryption keys Encrypted Video Muxing Key Provision
- 4. BITMOVIN and VUDRM Playback Encrypted Audio Muxing Widevine Playready Fairplay Encrypted Video Muxing DASH Manifest HLS Manifest Widevine Playready Fairplay License Servers
- 5. VUDRM TOKEN Purpose of VUDRM token • Authentication • Deliver the DRM policy to the License server vualto-demo|2018-03-07T14:40:41Z|RAQrLiTYv+Z8U9LrxO0JDw==|dded39344d643dad6c7c5ef12f44c3e17d65adb9 Client name Datetime token was created Encrypted policy Checksum Offline Playback: {"contentid":"CONTENT_ID","polbegin":"DD-MM-YYYY HH:MM:SS","liccache":true} Rental: {"contentid":"CONTENT_ID","polend":"DD-MM-YYYY HH:MM:SS","liccache":false,"firstplayback":172800} Subscription: {"contentid":"CONTENT_ID","polend":"DD-MM-YYYY HH:MM:SS","liccache":true} https://docs.vualto.com/projects/vudrm/en/latest/VUDRM-Token-Integration.html#json-parameters-for-drm-policies
- 6. VUDRM TOKEN and GEO-RESTRICTIONS Offline Playback: { "contentid":"CONTENT_ID", "polbegin":"DD-MM-YYYY HH:MM:SS", "liccache":true, "geo_whitelist":[“GBR“, “USA"] } GEO-LOCATION API Coming Soon!! { "contentid":"CONTENT_ID", "polbegin":"DD-MM-YYYY HH:MM:SS", "liccache":true, "geo_whitelist":["GBR", "USA"], "block_vpn_and_tor“:true } https://docs.vualto.com/projects/vudrm/en/latest/VUDRM-token.html#geo-whitelisting
- 7. VUDRM TOKEN and CONCURRENCY https://docs.vualto.com/projects/vudrm/en/latest/VUDRM-token.html#drm-session-in-policy Offline Playback: { "contentid":"CONTENT_ID", "polbegin":"DD-MM-YYYY HH:MM:SS", “polend”:"DD-MM-YYYY HH:MM:SS", "liccache":true, "session": { "id": “someSessionId", "url": "https://some-url.com/valid?sessionId=abc123", "methodType": “GET", "headers": [ { "headerKey": "headerValue“ } ] } , "geo_whitelist":["GBR", "USA"], "block_vpn_and_tor“:true } Offline Playback: { "contentid":"CONTENT_ID", "polbegin":"DD-MM-YYYY HH:MM:SS", “polend”:"DD-MM-YYYY HH:MM:SS", "liccache":true, "session": { "id": “someSessionId", "url": "https://some-url.com/valid?sessionId=abc123", "methodType": “GET", "headers": [ { "headerKey": "headerValue“ } ] } }
- 8. CMAF Goals • Standardized transport container for streaming using the MPEG-DASH or HLS protocols. • Simplify video streaming workflows. • Reduce Latency • Reduce Costs
- 9. CMAF LOW LATENCY CHUNK FRAGMENT SEGMENT https://bitmovin.com/cmaf-low-latency-streaming/ ENCODER PLAYER
- 10. CMAF and VUDRM CTR CBC CBCS
- 11. THE BIGGEST PROBLEM IS DISAPPEARING https://blogs.akamai.com/2020/09/cmaf-this-is-the-way.html
- 12. QUESTIONS?
Notes de l'éditeur
- Video Orchestration & Delivery with simple and comprehensive control of all live, VOD and Live2VOD activity, combined with DRM & Player Integration, all through a central API & GUI. The VCH is constantly evolving to include features such as: LIVE STREAMING: Comprehensive workflow management of live channels, from encoder and streaming server configuration to distribution. VOD STREAMING: Supports complex VOD preparation and delivery workflows via our VOD Task Engine tool. LIVE2VOD: Make your live stream available for instant on-demand viewing, or create VOD assets from live streams for longer term archiving. CLIP2VU: A live and VOD video clipping and syndication solution, powered by the VCH. DYNAMIC PLAYOUT PROFILING: Supports the creation of multiple playout profiles to be applied to live events ‘on-the-fly’. DYNAMIC SCALING: Live events can be scheduled, and the necessary resources needed can be spun up in your chosen cloud just prior to the event starting. ---------------------------------------- VUDRM allows you to securely deliver live & VOD content to your chose audiences across multiple devices, staying in control of who watches your content and when. Our device agnostic DRM is trusted by broadcasters globally, delivering millions of licences per day. MULTI-DRM SUPPORT with Microsoft PlayReady, Google Widevine, Apple FairPlay Streaming. EVOLVED INFRASTRUCTURE for increased monitoring, scalability and fault intolerance, using Kubernetes container orchestration. NO NEED FOR RE-ENCRYPTION using VUDRM flexible tokens to allow individual rights for each user. SCALABLE & RESILIENT currently delivering multi-million licences per day for major broadcasters and content owners, on a global scale. MULTI-PLAYER INTEGRATION with multiple options to include: Bitmovin, THEOplayer, JW Player, Radiant Media Player and open source players. 24/7 NOC MONITORING & SUPPORT tackling potential issues as they happen, ensuring stable, consistent & high quality streaming for your audiences.
- The VUDRM token has two purposes: authentication and the delivery of the DRM policy to the license server. It also represents a signed authorisation on the client’s behalf for Vualto to issue a DRM license to the holder of the token, issuing a VUDRM token to a player will grant that player access to the DRM-protected content. Due to the first purpose VUDRM tokens have a limited lifetime and are designed to be single use. Please contact support@vualto.com if you do not know what the VUDRM token’s TTL is for your account. The second purpose allows the user’s playback rights for individual pieces of content to be set dynamically. A single user may be granted different rights on a single piece of content depending on business requirements. VUDRM tokens should be generated using the VUDRM token API. The request to the VUDRM token API should be made from a server side application and the VUDRM token should then be delivered to the client side for use by a player in a license request.
- Can be used to retrieve geographical location information about IPv4 or IPv6 addresses.
- It is possible to set in the policy used by VUDRM token information about the current DRM session. With this information we will make a request to make to an API of your choosing with an ID and any needed headers. You can set the request to be either a GET request or a POST request. In the case of a GET request we would make a GET request to the URL you specify with a query string parameter called sessionId set to ID the passed in the policy. E.g. a GET request to https://some-url.com/valid?sessionId=abc123. In the case of a POST request we would make a POST request to the URL you specify with the body of the request being the sessionId in JSON. E.g. a POST request to https://some-url.com/valid with the body being {"sessionId":"abc123"}. The result of the request we make will dictate whether or not a license is returned. If the result is a 200 we will serve a valid license back. If the result is not a 200 we will not return a valid license.
- In 2016 Apple and Microsoft proposed a new standard called the Common Media Application Format (CMAF) to MPEG. HLS uses .ts containers DASH uses mp4 containers -> ISOBMFF: ISO Base Media File Format By using a single common format it means not encoding and storing the same content twice. This can be VOD storage or CDN storage. For DRM it means using a single encryption mode. HLS and dash streams are both now using Common Encryption (CENC) and importantly for later the same encryption algorithm. So again saving costs, encrypt one instead of twice.
- CMAF involves breaking the video into smaller chunks of a set duration, which can then be immediately published upon encoding. That way, near-real-time delivery takes place while later chunks are still processing. Previously an encoder would have to A chunk is the smallest unit. A fragment is made up of one or more chunks. A segment is made up of one or more fragments. Traditionally, the encoder would wait to create a full segment before sending it on to maybe a CDN. Then when the CDN had received the full segment, it would then give it to the player. With chunked-encoded CMAF, encoded data is transferred down the distribution chain immediately, with chunks sent and received independent of one another. This decouples latency from segment duration. In other words, the same latency can be obtained from a ten-second segment as from a one-second segment. 1st diagram from bitmovins website: The mdat holds a single IDR (Instantaneous Decoder Refresh) frame, which is required to begin every “segment” The “moof” box as shown in the diagram, is required by the player for decoding and rendering individual chunks. At the transmit end of the chain, encoders can output each chunk for delivery immediately after encoding it, and the player can reference and decode each one separately. 2nd diagram from bitmovins website. In the diagram shown above, player buffering and decoding behavior is shown, contrasting the standard segment (standard latency) mode with the chunked segment mode, corresponding to low latency streaming. The diagram shows that in non-chunked segments, with a segment size of 4xC (where C is the size of the lowest granularity unit, the chunk, measured in milliseconds) and three-segment buffering, a 14xC-second player latency is typically achieved. In contrast, chunked segments with CMAF are shown to achieve a 2xC second latency as opposed to a 14xC-second latency, thereby achieving a 7 times improvement in latency. Chunked-encoded and chunked-transferred CMAF will allow OTT to compete directly with cable and easily beat the user experience because of the other technologies we have available to enhance the “video experience”.
- While CMAF DRM is based on common encryption (CENC) the problem is that Fairplay used CBC encryption while Widevine and PlayReady use CTR. CBC and CTR are both part of CENC but both represent fundamentally different ways of encrypting content. This means you still do not have a single variety to stream out, defeating the object of CMAF (ignoring the fact that you still need two manifests of course). So what changed? CBCS encryption was always supported by Fairplay but then PlayReady and Widevine agreed to support CBCS and the VUDRM services were updated with these changes.
- The biggest problem with the adoption of CMAF and CBCS was device support. This is becoming less of a problem daily as CMAF and CBCS are now supported on a large portion of end user devices. As can be seen in this graph from Akamai, over 75% of all devices now support CMAF and CBCS in Q2 of this year. 25% is a significant number of devices, and this includes devices such as the PS4 and Smart TVs. Tizen from Samsung and WebOS from LG added support for PlayReady v4 with the CBCS support. But LG 2017 TVs browser technology is based on Chrome 38! This upward trend in device support is why we think you should do something now. In my opinion if you do not need DRM then you should be using CMAF now. There is no reason to not. If you need DRM then you need the device to have CBCS support, so start your migration. Add CMAF and CBCS to your workflow, use it where possible and fallback to CTR when the device does not have CBCS.