Video: What Are the Key Features of CMAF?

Learn more about CMAF at Streaming Media's next event.

Watch John Gainfort's complete presentation, VES 102. Deploying CMAF in 2019, in the Streaming Media Conference Video Portal.

Read the complete transcript of this clip:

John Gainfort: What are the key features of CMAF? It allows for unified segments across your different manifest and it offers some improvements with your RAM.

First, let's talk about some unified segments. Before, when you were encoding and packaging your content, you had a package for both HLS and DASH. HLS was using MPEG-2 TS container formats. DASH was using its own MP4 format. So you would have to have two separate segments and then store both of those segments at the same time.

Now, with CMAF, you can have the same segment packaged for both HLS and DASH, and you only have to store one segment instead of two. If you were utilizing both HLS and DASH player, now you can keep doing that, or you could make a switch for one and be unified across.

Unified segments lower your production costs associated with encoding, packaging, and storage. That's a big key benefit. It can significantly improve your CDN cache efficiency, especially for live video streaming. It adds in a foundation to define additional conformance points for content and devices regardless of manifest protocol, and what I like most about this is that it provides common ground for industry cooperation.

It's worth noting that if you are using HLS, you need to specify version 6 and above. Some players like ExoPlayer, HLS, JS Bitmovin, they probably won't care about this version, but then if you plan to use Safari, AVPlayer--so, anything Apple--they are very strict and they do require that this version be set.

Moving on to some DRM, what CMAF offers with DRM is cross-platform and media format compatibility so right now CMAF will be supported out of the box by AVPlayer, ExoPlayer, and Safari. It allows for single encoding and encryption. This is because of common encryption.

With CMAF, as I mentioned before, we do not require transmuxing on the client's side. So what we can do now with CMAF is a single packaging workflow when it comes to DRM, and single-pack publishing.

Let's look at some quick terminology. I'm going to stay to the two highlighted ones. We have common encryption AES-CTR, which I'm going to refer to as CENC, and we have CENC at the bottom, AES-CBC Pattern or CBCS.

The big challenge is CBCS compatibility. CBCS is being utilized by Apple so Apple FairPlay, and all major browsers are moving forward to supporting CBCS. While CBCS is not working at Firefox right now, however, this is coming in the near future. It's working in Safari, it's working in Chrome, and a few other major browsers, but CBCS is also not supported in Edge. However, that is going to be changing with their introduction of their new Chromium-based browser that is currently in beta right now. We are expecting that to be released in the next year.

As mentioned earlier, CMAF does not allow mixed audio, so what that means is both audio and video renditions could need to be decrypted and possibly have different decryption keys for both audio and video so you can beef up some of your decryption DRM capabilities.

One major challenge is that open-source player availability is somewhat limited. Currently, Shocka Player does not support Play Ready or FairPlay. HLS-JS doesn't currently support any DRM. However, we have an open PR with HLS-JS to include Widevine into their platform, but both of these platforms have other people providing, or doing ongoing efforts to support this.

So what are the options right now? One thing we're pushing for is having two manifests with two fragment encryptions for Widevine. So we're targeting CBCS so we can support Apple, Android, Roku, Chrome and Safari. But then using CTO--or CENC--to support Firefox and Edge with the goal of moving towards CBCS as more browsers adapt to it. If you're using Android and you need to target older Android devices, you'll need to stick with the CENC because CBCS wasn't introduced until 7.0.

Another option that you also have is you can roll your own to your own workflow for your player, using EME, or Encrypted Media Extensions. EME was designed to enable the same app and encrypted file SKUs in any browser, regardless of the underlying protection scheme. You can encrypt once and decrypt in any browser using any of those schemes that you need to use. So for Safari you can use FairPlay; Edge, PlayReady; Chrome and Firefox, Widevine. This enables you to contribute to the community since we're using common formats.

Here's a quick support matrix. CBCS is supported across the board between FairPlay, PlayReady, and Widevine. However, with Edge we're looking at having to wait until their new Chromium-based browser comes out, and for Firefox, it's supported now, but I couldn't tell you exactly which version started to support it. For CENC, Apple devices--so your iOS, your TVS-- will not support CTR, and Safari devices will not support it either.