Akamai Diversity

The Akamai Blog

CMAF... This is the Way

Optimize your streaming content catalog

The debate is over. Common Media Application Format (CMAF) has delivered on its promise: one package to serve them all. Two of the highest profile direct-to-consumer (DTC) streaming service launches recently made the leap, validating that the time has come for CMAF.

CMAF provides a number of advantages that make it attractive for video services to adopt:

  • Reduced costs to prepare, store, and deliver content
  • Enhanced cache efficiency and origin offload
  • Improved support for low-latency livestreaming

Looking back at 2015

Before CMAF, most of the modern streaming world was divided between Apple's HTTP Live Streaming (HLS) and MPEG's DASH. As you know, CMAF is an encapsulation format -- a way of packaging up the data for transport. Historically, HLS relied on MPEG-TS encapsulation, an easy transition from legacy broadcaster video infrastructure. But HLS was burdened with arcane data structures and unnecessary overhead due to the noise protection required in the radio networks it was built to serve. 

The implementation of MPEG DASH, on the other hand, tended to lean into the more optimized and IP network-friendly ISO Base Media File Format (ISOBMFF) encapsulation based around fragmented MP4. It is not all gravy with DASH -- the technique's flexible and open approach can lead to some complex integrations between components.

CMAF is an evolutionary step forward from ISOBMFF, adding important structures and options that make it compatible with all current and forward-looking data types that content publishers are interested in supporting. While Apple's decision to enable HLS support of CMAF was the catalyst for this change, it left operators with several important decisions.

CMAF is just a box we put media and data in. Most of the interesting stuff -- like ad insertion -- occurs at the manifest or application level. That's where we need to choose whether to address the CMAF segments from an HLS and/or DASH manifest.

If you want to use Apple's native player (and most people do), you must supply an HLS manifest. As a practical matter, this gave operators one choice: go HLS everywhere, since other devices are less prescriptive. But HLS isn't perfect, and some inefficiencies in it pushed other folks to adopt a DASH everywhere (except Apple) strategy. 

Maintaining two manifests drives up operational overhead but does not impact storage or delivery efficiency. The major gains are realized from having a common set of data objects. The manifests are relatively small text files that can be derived from one another.

Premium content 

The big sticking point impacts premium content owners. While Apple acceded to support CMAF, it stuck to its preferred approach of AES128 encryption: Cipher Block Chaining Sample (CBCS) mode. The debate will rage over the incremental benefit versus the Counter (CTR) method, but the hard truth is that it left us with a population of devices in people's hands that were hard coded to one or the other. 

The good news, now that more digital water has run under the bridge, is that developers have been building CBCS support into all new devices. At least from here on out, they will support CBCS. Ladies and gentlemen, we have reached the moment. 

If you don't have premium content you are all set -- go forth and package once! 

Let's take a look at a couple of the sticking points for premium-content owners: SmartTVs pre-2020 and PlayStation 4 (PS4).

SmartTVs pre-2020

The two biggest players in the SmartTV segment are Samsung and LG, accounting for 11% of viewing time according to Conviva's State of Streaming Q2-2020 report.

In the last two years, viewership has exploded on native SmartTV apps because of the convenience for the end user. There is an irony here -- this shifted viewers from platforms with CBCS support to a patchwork of TV platforms that do not.

Samsung and LG, like others in industry, define the core firmware of the TV by the year model and crucially do not offer an upgrade path. Until 2019, both Tizen (Samsung) and WebOS (LG) up to 2019 supported up to PlayReady 3.x, and it wasn't until we got to PlayReady 4.0 that CBCS mode was included in the support. So, for year model 2020 forward, the two big players (75% of the SmartTV viewership) will now support PlayReady 4.x and hence CBCS.

If history is a guide, we can expect SmartTV apps to stop receiving upgrades and support after three years and become unusable after five years. The LG 2017 TVs core browser technology, for example, is based on Chromium 38! Do you want to write web apps for Chromium 38? Without ECMAscript?

Is this a major issue? In the near term, older less-SmartTVs can be made smarter with a low-cost stick. Those are something streaming services have given away with as little as a three-month commit. The stick/box platforms all (except the very dusty) have support for CBCS.

Game consoles

Game consoles move faster than TVs. PS4 doesn't support CBCS, again because of an older PlayReady port, but it is seven years old at this point. Come the holidays, the PS5 will be flying off the shelves. Looking back at the PS4 launch, within two years the PS4 overtook the PS3 as users switched over. Unlike the PS3 to PS4 transition, PS5 will be backward compatible with PS4 games from day one, so we expect PS5 adoption to be faster.

Where are we now?


Fig. 1 - CBCS for all devices / only major platforms

Figure 1 shows the current and predicted trend for audiences on devices that support CBCS based on viewing time spent per device. The blue line is an absolute number and should be considered very conservative as this tries to capture all devices. The green line is a more aggressive model, where we only consider operators targeting the most popular platforms: the top 3 connected TV devices and mobile devices, and the top 4 browsers. Under that model, as you can see, we are already at 96th percentile and should not lose sleep making the change.

If your target audience doesn't include SmartTV apps for pre-2020 models or PS4, you could be ready to package once to CMAF/CBCS. But there are also some local market nuances to watch. 

For example, if you have an audience on third-generation Apple TV, which is a very small percentage of the global picture, but for you that might be a constituency you care about. The issue here is that only fourth-generation Apple TV and higher can run tvOS 10, hence support CMAF. Similarly, you might have an audience on a custom Android tablet that is pegged at a pre-Nougat (7.1) that lacks CBCS support.

Making the shift

Okay, say you're convinced. But you're going to have to support CTR mode for maybe a couple of years. What is the best way to handle this? The answer is to serve a CBCS asset to everything that can accept it. From a delivery performance standpoint, the more devices that select CBCS, the higher the chance the object is in cache and will have a better performance.

Over time as the usage of the CTR version of an asset drops, you can simply withdraw that from the origin and make it available only to CBCS devices. What's the best way to do this? Next, I outline three approaches: lookup, try, and test.


Using a back-end management process or similar technique, a lookup approach uses the client's app version or UserAgent to select whether the CBCS or CTR version is sent to the client. For example, if the client is Safari, send CBCS; if Chrome, send CTR; if Roku, send CTR; if AppleTV, send CBCS; and so on.

Lookup covers the lowest common denominator. It's the safest option but results in a minority of older devices defining an entire class -- and that minority could consist of a single box. This approach drags out the curve at a much shallower angle than actually represents your user base, prolonging the time to convergence and maintaining bifected workflows and double storage. While essential to browser logic now, UserAgent will become less reliable in the future with the push from Apple and others to obfuscate it in response to fingerprinting and privacy concerns.

Including a hardware revision to the mix can speed up the process:

For example: LG < 2020 send CTR, LG >= 2020 send CBCS

In the limit this achieves an optimum split. The problem with this approach is that new versions are being added every day, leading to maintenance overhead.


Load the CBCS asset but have a catch / fallback to CTR on failure. This step is worth adding to any client as a general safety net. Couple it with strong reporting so developers can understand if the failure is a real problem with the client or an implementation issue.

The advantage of pushing most users to CBCS is you have a rolling window of transition. If there are clients with marginal implementations, they can always fallback to the CTR version. However, new devices are added to the pool of CBCS viewers without explicit changes to client or back-end systems.


Detect capabilities of the client running at startup or initialization. If done well, this avoids the maintenance of the lookup approach outlined above and as new devices appear, the client will probe for capabilities and select which will work. This approach solves for a new version of OS breaking something that worked before.

There are some issues to watch for that can arise with incomplete implementations of detection. Here is a simple web page that checks basic decryption and decoding capabilities as advertised by a browser's MSE/EME APIs. The calls may not return comprehensive data, especially on older platforms, so it's worth carrying out more extensive checks to verify the accuracy of the advertised capabilities.

Future manifest

In order to achieve an optimum approach, ensure that the CBCS manifest is a superset of the DRMs that require support. An example follows:


CBCS mode may not be the default choice for Widevine and PlayReady in your packager -- some might not expose the option. Check with your packaging partner to make sure they are updated to at least offer the option, and ideally make it the default.

The way forward

If you don't need encryption, you should already be packaging your content in CMAF. If you have premium content that needs DRM, check your client universe to see if you can sidestep supporting CTR from this point forward. If you really can't avoid it, build your CBCS manifest(s) to include all the DRMs, and then ask your client to detect if it can play CBCS, failing back to CTR if it can't or won't.

By steering as many of your users to your future packaging format as soon as possible, you will start on the most optimal path to reducing legacy complexity of delivery out of your workflow, freeing you to concentrate on other functionality that increases value for your audience and drives up viewership.

This is the way.