Perspective
CMAF – The future of OTT streaming
The OTT industry has evolved from the legacy RTP, RTMP, and flash streaming to more advanced streaming protocols like HLS, DASH, smooth streaming, and HDS with support for adaptive bitrate streaming over the past couple of years. HLS and DASH emerged as the most popular choices among OTT service providers and have been used widely.
Even though the OTT world has seen many technological improvements, video streaming to various devices running different operating systems mandating the use of different streaming protocols has always posed a challenge to the service providers. While they need to figure out the optimal streaming resolutions and respective bitrates to support content streaming on said devices, the content has to be packaged differently to deliver HLS and DASH streams to respective devices. This introduces a lot of commercial and operational overhead on OTT service providers owing to additional processing, storage, and distribution.
Sports streaming, which is driving mass user engagement has about 5 seconds of pipeline delay in traditional broadcasting mechanism via satellite, while the standard delay of live OTT streaming is more than 10–15 seconds in practice. Thus, the need for low-latency streaming (~5 seconds stream delay from origin till end-user) for sports events was being felt strongly among service providers and the end-users. All of these paved ways for the development of a common streaming format that can be used independently on any device as well as it should be capable of offering low-latency OTT streaming.
Released in January 2018, Common media application format (CMAF) is jointly developed by Apple and Microsoft.
CMAF format. CMAF specified the use of fragmented MP4 (fMP4) or ISO base media file format (ISO BMFF), which is also used by DASH. It can be represented by HLS and DASH manifests, and hence avoids the need to create separate packaging for different streaming formats, saving cost and operational overhead.
Container format: ISO BMFF (fMP4); Video Codecs: AVC, HEVC, VP9 (later); Audio Codecs: AAC-LC, HE-AAC and HE-AACv2; Encryption Algorithm: Common encryption(CENC); Encryption modes: CBC and CTB; Subtitles: WebVTT and IMSC-1; Closed captions: CC608 & CC 708 (via SEI).
Initially, since the DRMs had support for either Counter (CTR) or Cipher Block Chaining (CBC) encryption modes depending on the target platforms which necessitated the need of using different encryption methods and hence, required a separate packaging with supported encryption. CMAF specifies the use of CENC for encryption, which can support CTR and CBC modes, thus streamlining the use of a single media-processing pipeline. Widevine has started supporting CBC while PlayReady has added support for CBC from v4.0+. This makes CBC as the common cipher algorithm, which can be used by all DRMs.
Single content packaging using ISO BMFF container eliminates the need for producing multiple copies of the same content to support various streaming formats. Thus, costs related to content re-packaging/re-transcoding and maintaining content copies in CDN cache are nullified. The use of a common container format and CENC for encryption requires a single media pipeline to be maintained and thus reduces the operating complexity. Use of CMAF container eliminated the muxing and other typical overhead carried by TS packets, while at the same time delivery of presentable data chunks reduced the decoding time making way for low-latency playback.
CMAF has simplified the OTT streaming workflow enabling low-latency streaming and is certainly the future of OTT streaming. Being a new technology, it would need fast adoption of its standards from the entire OTT ecosystem, starting from packagers to client devices. In the present scenario, there are many legacy devices (like Android v6.0 or below) and browsers, which do not support CMAF (with CBC) as of now and hence, a wise decision has to be made balancing all the parts while adopting CMAF.
You must be logged in to post a comment Login