Streaming protocols break down video content into small chunks that are delivered sequentially to viewers for reassembly and playback. This overcomes limitations of standard video formats for storage and playback. Common streaming protocols include HTTP Live Streaming (HLS), Dynamic Adaptive Streaming over HTTP (DASH), and Microsoft Smooth Streaming (MSS). These protocols support features like adaptive bitrate streaming and digital rights management (DRM). DRM uses encryption and licenses to restrict playback of protected content and is implemented through standards like Encrypted Media Extensions (EME) and content decryption modules (CDMs).

1. OTT STREAMING PROTOCOLS AND
DIGITAL RIGHTS MANAGEMENT (DRM)
MUHAMMED ASIM YILDIZ

2. WHAT IS A STREAMING PROTOCOL?
 A Streaming Protocol is:
 A standardized delivery method for breaking video into chunks
 Sending it to the viewer
 Reassembling it on the viewer

3. WHY NEED STREAMING PROTOCOLS?
 Most digital video is designed for:
 Storage (small file sizes)
 Playback (universal playback)
 Most standart video formats are not designed for streaming
 In order to stream a video:
 Video needs to be converted to a streamable file
 A streamable file consists of chunks
 These chunks arrive sequentially and playback as recevied

4. STREAMING PROTOCOLS ADVANTAGES
 Streaming protocols can get much more complex
 Many are “adaptive bitrate” protocols
 Deliver the best quality that a viewer can support at any given time
 Some protocols focus on “reducing latency”
 Some protocols “delay” between an event and viewer
 Some protocols focus on “DRM”
 Some protocols work only on certain systems

5. PROTOCOL – CODEC – CONTAINER FORMAT
 Codec refers to “Video Compression Technology”
 Different codecs are used for different purposes
 For example:
 Apple ProRes is often used for video editing
 H.264 is widely used for online video

6. PROTOCOL – CODEC – CONTAINER FORMAT
 Format simply refers to container format of a video file
 .mp4, .m4v, .avi, .mkv
 A container format is like a “box” that contains:
 A video file
 An audio file
 Metadata
 Container format isn’t a central concept for live streamers

7. STREAMING IN REAL-LIFE
 Imagine that you’re a merchant, and you’re transporting clothing in bulk
 The clothing represents the video content
 The streaming codec is the machine that compresses the clothing into a bundle to save space
 The container format is the boxcar that these bundles are packed inside
 The streaming protocol is analogous to the railroad tracks, signals, and drivers who deliver it to the
destination

8. STREAMING IN OTT
 Generate multiple versions of the same content (e.g. different bitrates, spatial resolutions)
 Chop these versions into segments (e.g. two seconds)
 The segments are stored in a web-server and can be downloaded with HTTP GET requests
 The relationships between different versions is described by a manifest file
 The manifest file is provided to the client prior to the streaming session
 Manifest represents different qualities of the media content
 Manifest has individual segments of each quality with URLs
 This structure allows to bind to segments to the bitrate, among others (start time, duration of segments)

9. STREAMING PROTOCOLS
 HTTP LIVE STREAMING (HLS)
 DYNAMIC ADAPTIVE STREAMING over HTTP (MPEG-DASH)
 MICROSOFT SMOOTH STREAMING (MSS)
 REAL-TIME MESSAGING PROTOCOL (RTMP)
 WEB-RTC
 SECURE RELIABLE TRANSPORT (SRT)
 REAL-TIME STREAMING PROTOCOL (RTSP)

10. HTTP LIVE STREAMING
HLS
 Apple created it in 2009
 Built to drop Flash from iPhones
 Supported by:
 Desktop browsers
 Smart TVs
 Android and iOS mobile devices
 HTML5 players also natively supports

11. HTTP LIVE STREAMING
HLS
 HLS supports:
 Adaptive-bitrate streaming (High Quality)
 Supports the common H.264 codec
 Supports latest H.265 codec
 Secure streaming
 The major downside is high latency

12. DYNAMIC ADAPTIVE STREAMING OVER HTTP
MPEG-DASH
 The only international standardized solution
 Created in 2012
 Currently adopted by YouTube, Netflix etc.
 Most big companies have contributed to standardization

13. DYNAMIC ADAPTIVE STREAMING OVER HTTP
MPEG-DASH
 MPEG-DASH supports:
 Adaptive-bitrate streaming (High Quality)
 Codec agnostic (can be used with almost any streaming encoding)
 It supports standards-based APIs for browser based DRMs:
 Encrypted Media Extensions (EME)
 Media Source Extensions (MSE)
 The major downside is no compatibility with Apple Devices/iOS

14. MICROSOFT SMOOTH STREAMING
MSS
 Microsoft created it in 2008
 Targeting the smooth delivery of HD contents over IIS
 Based on fragmented MP4 files

15. MICROSOFT SMOOTH STREAMING
MSS
 MSS supports:
 Adaptive-bitrate streaming (High Quality)
 Includes CPU utilization for adaptive-bitrate streaming
 Supports the common H.264 codec
 The major downside is MSS limits the use of Smooth Streaming to CDNs using Microsoft Products

16. STREAMING
COMPARISO
N

17. STREAMING
COMPARISO
N

18. STREAMING
COMPARISO
N

19. DIGITAL RIGHTS MANAGEMENT
DRM
 DRM refers to the algorithms and processes
 DRM enforces copyright compliance when consuming video content
 Without DRM, content can be easily copied
 DRM is not visible to the consumers
 DRM is also used offline to provide copyright protection for CDs, DVDs, and BluRays

20. DRM TECHNOLOGIES
 Fairplay: Cipher Block Chaining encryption
 The only option for Safari and is only used by Apple devices
 Widevine: Developed by Widevine Technologies, bought by Google
 Used on Android Devices natively, in Chrome, Edge (soon), Roku, Smart TVs
 PlayReady: developed and maintained by Microsoft
 Supported on Windows, most set-top boxes and TVs

21. DRM
TECHNOLOGIES

22. DRM
TECHNOLOGIES

23. DRM IN REAL
LIFE?

24. DRM IN OTT?

27. DRM ENCRYPTION KEYWORDS
COMMON MEDIA APPLICATION FORMAT (CMAF)
 There are primarily two protocols in use today – MPEG-DASH and HLS
 MPEG-DASH uses the mp4 container and HLS uses the MPEG-TS (ts) container for its video files
 Duplicate contents (doubled storage size)
 When also adding DRM
 If we use the 3 hypothetical DRM providers with 3 different encryption standard, then we need 2*3=6 copies of
the video
 The CMAF specification was created
 Store files in the fragmented mp4 container format (fmp4)
 With support from both MPEG-DASH and HLS, we now create only one set of videos, store it in fmp4 format

28. DRM ENCRYPTION KEYWORDS
COMMON ENCRYPTION SPECIFICATION (CENC)
 If different DRM technologies use different encryption standards
 We still need to store multiple copies of each file
 For this purpose, the MPEG developed the CNEC
 Videos can be encrypted using either CENC (AES-128 Counter-CTR) or CBCS (AES-128 Cipher Block Chaining-CBC)
 The implication of CENC
 A content provider needs to encrypt videos only once and any decryption module can decrypt it
 Note: Exposing the encryption algorithm is not a problem as long as the keys are strongly protected.

29. DRM ENCRYPTION KEYWORDS
ADVANCED ENCRYPTION STANDARD (AES)
 AES is a symmetric-key algorithm: encryption and decryption are performed using the same key
 It has three variants based on the key-length:
 128, 192, and 256 bits. The longer the key, the harder it is to crack.
 Cracking the AES-128 without the key would require a “billion times a billion years” and a super-
computer

30. HOW DRM WORKS?
ENCRYPTION
 Communications between the requesting playback software and the license server are encrypted
 Each segment is encrypted according to the MPEG Common Encryption (CENC) specification
 The MPEG-CENC standard is comprised of XML style formats
 The MPEG-CENC standard requires a minimum of a key and key id to run
 Standard content encryption is done according to the Advanced Encryption Standard (AES)
 Using 128-bit keys and a Cipher Block
 Cipher block is either Counter Mode (CTR) or Cipher Block Chaining (CBC)
 Only the audio and video data within a segment is encrypted

32. DRM DECRYPTION KEYWORDS
ENCRYPTED MEDIA EXTENSIONS (EME)
 Encrypted Media Extensions (EME) is a JavaScript API
 EME is an extension to the HTMLMediaElement specification
 EME provides an API that enables web applications to interact with content protection systems
 EME allows playback of encrypted audio and video
 EME is designed to enable the same app and encrypted files to be used in any browser, regardless of the
underlying protection system

33. DRM DECRYPTION KEYWORDS
CONTENT DECRYPTION MODULE (CDM)
 Content Decryption Module (CDM) is a software that decrypts and optionally, decodes + displays the
video.
 Every DRM provider provides its own:
 Mechanism to create a license request (using the KeyID, device identifier, signing the request, etc.)
 Mechanism to understand the license response received from the DRM License Server (the response is encrypted
too) and extract the decryption key
 Rules around storing the license locally on the client, license renewal, expiry, etc
 CDMs (Content Decryption Modules) is built into browsers such as Chrome, Firefox, Microsoft Edge,
Safari

34. DRM FLOW
 Obtain the movie & its manifest from the CDN
 Extract the KeyID from the manifest
 Create the license request
 Send the license request to the license server
 Wait, listen, and receive the response from the license server.
 Use the decryption key from the server to decrypt the content
 Decode the decrypted content
 Display the decoded movie

37. HOW DRM WORKS?
DECRYPTION
 When a web player identifies protected content:
 It calls on processes and interfaces defined by Encrypted Media Extensions (EME)
 Browsers will initiate a license request process
 License requests are generated by Content Decryption Module (CDM )(all of the decryption is done by
CDM)
 Passed to the players through the EME (EME is just simply an interface)
 The player calls the appropriate function on the EME interface
 Then the sessions are updated by the CDM
 The EME interfaces with the CDM handles the decryption of the segments on browser or OS level

38. HOW DRM WORKS?
CLIENT-SIDE
 The license acquisition using the EME starts from the playback client
 Creating a key session unique to the client, device, and the metadata found in the segments
 The CDM then generates a signed key message.
 The client then sends then secured message to the license server
 The license server returns the requested license
 With the resulting decision of whether or not the client is granted playback rights to the requested content
 If not, playback is halted and an error is shown.
 In successful communications scenarios, the client updates the session data with a returned license
 The content decryption is handled fully by the CDM
 In some circumstances, the license is cached for a set time and can be used to playback protected content offline
 The license and the decrypted data must not be accessible to clients other than the licensed content requester
 Therefore, the private keys and decrypted data are kept in a secure environment within the browser, operating system, and hardware
(if supported), like Trusted Execution Environments.

39. THANK YOU MUHAMMED ASIM YILDIZ