The Common Media Application Format (CMAF) has been around since 2016. While CMAF has attracted most attention through its support of low latency live streaming, we see considerable financial and performance benefits when it is deployed into a VOD workflow.
This article is a follow-up to my presentation at this year’s Streaming Media West conference. It details how CMAF drives down the infrastructural cost of storage and packaging and improves playback performance thanks to its simplified cacheability. It also discusses the limitations of CMAF’s deployment, primarily in regards to its integration with multi-DRM services.
The Rise of CMAF
CMAF can be described as a format that utilizes a single standardized container.
It came to life through the collaboration of Apple and Microsoft in 2016. The primary goal of this effort was to challenge the inefficiencies in encryption, packaging, storing and caching of the content.
The advent of CMAF was conditioned by Apple’s HLS support of fmp4 (ios 10 or higher) – the container that was used by MPEG-DASH for many years. CMAF is manifest agnostic so we do not think of it as a successor of HLS and MPEG as it does not solve the manifest fragmentation. Quite the opposite, as it still utilizes HLS (m3u8) and MPEG-DASH (mpd).
VOD Workflow Scenarios
To understand how CMAF may help to simplify the VOD workflow, let’s review the processing and delivery models.
HLS + MPEG-DASH static packaging
In this scenario, separate chunks are created for HLS and MPEG-DASH. It doubles the storage space requirements as well as the CPU capacity employed for content packaging.
HLS + MPEG-DASH dynamic packaging
In this scenario, multi-quality mp4 files are stored. The content is chunked and packaged “on the fly” upon the client’s request. It solves the storage space duplication. Benefits on the CPU level are rather questionable as the CPU usage is highly use-case sensitive.
Furthermore, the fact that chunks are created only after they requested by a client (for the first time), may add to the latency of the first request.
And now, let’s get to the most troubling part of these two scenarios (at least from the CDN perspective). Creating two identical copies of the same file – each transferred in a different container – also doubles the number of files to cache at the CDN edge level. Given that every single chunk represents a very short sequence of the video (usually between 2-10 seconds) and it often comes in 4 or more profiles (adaptive qualities), this multiplication unnecessarily floods the cache servers with thousands of files for every single piece of content.
The implementation of CMAF creates a solution to all these challenges. It cuts down the requirements for storage space, encoding power and reduces the number of files in cache which results in performance benefits.
Since CMAF utilizes HLS and MPEG-DASH manifests, its integration requires no more than changing your packager output to CMAF. The content is accessed through identical links as with HLS and MPEG-DASH when packaged separately. Taking all the above into consideration, you might be asking why the market has not yet adopted CMAF at a larger scale. The answer lies in its accessibility.
Support for CMAF
Apple adopted fmp4 in 2016 and it is supported by all devices with iOS version 10 or higher. It means that over 90% of Apple’s ecosystem will support CMAF (with exceptions of iPhone 4, The Original iPad and the iPod Touch 4th generation that cannot be upgraded to iOS10). Android supports CMAF from version 7.1.
Furthermore, The trouble may start with non-Apple devices that lack the support of ISOBMFF and still rely on HLS with M2TS. The main compatibility issues are associated with legacy devices which have been retired by their manufacturer. They range from the first generation of Google Chromecast to early Roku devices, as well as an extensive range of legacy Smart TVs and set-top boxes. The issues are mainly associated with no more updates being released to the newest OS which limits the compatibility of devices with new standards such as CMAF.
DRM & CMAF
The real challenge occurs when you encrypt your content using multi-DRM formats. Although the major DRM services (Fairplay Streaming by Apple, Google Widevine and Microsoft Playready), adopted a standardized procedure for enabling video content protection called Common Encryption (CENC), the devil still lies in detail.
CENC has been supporting two major block cipher operational modes:
- AES-128 CTR – Counter
- AES-128 CBC – Cipher Block Chaining
While Apple has been always faithful to AES-128 CBC, Widevine and Playready were historically using AES-128 CTR. As the encryption takes place at the data level (before it gets encapsulated into a transport container) the multi-DRM implementation has forced us to duplicate video chunks CMAF notwithstanding.
The major shift towards unified encryption is marked by the recently adopted support of AES-128 CBC by Widevine and Playready (version 4). Once AES-128 CBC is employed as a unique encryption method, CMAF will allow for a full-fledged “package once, serve many” streaming solution.
This is great news indeed. Yet, we still need to wait a little longer to see this simplification deployed in production. Widevine and Playready using CBC are supported only in the recent versions of most browsers. Also, a vast array of older devices is unlikely to receive these required upgrades. As such, the audience reach of “CBCed CMAF” is still painfully limited.
CMAF has already shown to be a great solution for the delivery of non-premium content. It has proven to cut down CPU usage and storage requirements while doubling the caching efficiency at the CDN level. Although the format is widely accepted, you may think of your audience reach before implementing CMAF to make sure your viewers are not left behind.
With Widevine and Playready pursuing CBC block cipher, CMAF is set off to become a unified solution which the industry has longed for. The future seems bright. Now we simply need to wait for many devices to be phased out before CMAF demonstrates its full potential in the field of premium content.