In today’s video streaming industry, the most dominant HTTP Adaptive Bitrate Streaming technologies are HLS (HTTP Live Streaming) and MPEG DASH(Dynamic Adaptive Streaming Over HTTP) which are serving video content to all the platforms and devices. The arrival of MPEG DASH with Common Encryption (CENC) made HSS (Microsoft HTTP Smooth Streaming) and HDS (Adobe HTTP Dynamic Streaming) to almost disappear. Based on the platform/device/browser, the streaming format is picked and content is delivered. For iOS clients, HLS is preferred and for Android/Windows clients MPEG DASH is the best choice.
The segmentation/fragmentation process, publishing the content into the Content Delivery Network (CDN) and delivering the content to Clients from the CDN based on the requests all together introduce more latency to Viewers compared to Satellite/Cable Broadcast TV and IPTV. This latency can vary for HLS and MPEG DASH.
HLS is using the Transport Stream (TS) as the container for Segments and Manifest files are Master Playlist and Media Playlist. Premium HLS content is encrypted with Fair Play Streaming (FPS) using encryption mode as Chain Block Chaining (CBC).
MPEG DASH mainly uses the Fragmented MP4 (FMP4) as the container for Segments/Fragments and maintains single Media Presentation Description (MPD) as Manifest. Premium MPEG DASH content is protected with CENC (PlayReady, Widevine) with encryption mode as Counter (CTR).
As the containers are different for HLS and MPEG DASH, for best practice, Content Publishers should choose either HLS or MPEG DASH as the storage format. Assuming that if the storage format is MPEG DASH then HLS serving should happens on fly and vice versa.
In the HLS to MPEG DASH conversion, generation of MPD and Initialization segment is not that complex compared to DASH segments. Parsing, Decrypting, Re-Encrypting and Transmuxing methods/procedures are involved to generate MPEG DASH segments from HLS and similar methods/procedures exist to generate HLS segments from MPEG DASH. This shows clearly that conversions will increase the latency further. If the Content Providers maintains the HLS and MPEG DASH as the storage formats then the storage footprint is almost doubled. The caching modules have to cache the same content in different containers.
To overcome most of the issues existing with MPEG DASH and HLS and to provide the best user experience, Microsoft and Apple have agreed for a common format for streaming the video content i.e. Common Media Application Format (CMAF).
Single Container but Manifests will differ (Reduces cost and complexity):
CMAF segments are purely based on the Fragmented MP4 and there won’t be TS segments support. The Segments/Fragments/Chunks will be in the FMP4 format for all devices and platforms.
Common Encryption based common media (Reduces cost and complexity):
Apple/iOS devices are also going to support the CENC based FMP4 content. For all devices and platforms, media segments remain the same. PlayReady, Widevine and FPS are going to support CBCS mode for encryption.
Low Latency due to Chunked Encoding and Chunked Transfer-Encoding (Closer to Broadcast):
To get the low latency, Encoder should have support for CMAF for Chunked Encoding and also there should be support for chunks transfer encoding between CDN and Clients. Chunked Transfer Encoding allows for transmitting of the segment while it’s being generated, thereby reducing the latency to sub-segment duration.
Challenges with CMAF:
It may take few years for CMAF to evolve in the market as the CMAF doesn’t have backward compatibility for older devices/clients and also existing VOD/Recorded DASH/HLS content. HLS Segmenters/Clients need enhancements to support FMP4 segments. Encryption standards (PlayReady, Widevine and FPS) need to upgrade for CBCS mode for CENC. If CMAF is able to deliver the content much closer to broadcast then there will be much impact for Server-Side Ad Insertion workflow. Present available Encoders which are capable of providing the HLS and MPEG DASH content also need up-gradation.
