This past summer marked the third anniversary of the announcement of CMAF, the Common Media Application Format developed to increase the interoperability of streaming video. Since its inception, it has been adopted at an impressive speed. This was especially clear at IBC this year, where it was no longer the new kid on the block, but the de facto standard for fMP4 contained media. CMAF was everywhere (in hall 14, that is…). But… was all of it really CMAF?
Or: how can you establish whether something that is labeled as CMAF does indeed conform to the CMAF specification?
This question is more than just a theoretical exercise. It is of critical importance when you want to guarantee interoperability, the main selling point of CMAF. If you commit to CMAF and are going to potentially repackage a big VOD library, you don’t want it to be ‘almost’ CMAF, with some minor deviations. You want it to be as on spec as possible.
The good news is that there is some tooling out there to help you check for conformance. This blog post explains what this means, and how to do it.
But first, let’s travel back in time for a bit of useful background…
At breakneck speed
Almost immediately after the first word was out on CMAF, Apple – one of the initiators of the specification – announced that it would start supporting it in its widely adopted HLS streaming protocol, which up until then had only allowed for MPEG-TS. Through its iOS and macOS software releases of fall 2016 Apple delivered on that promise.
We immediately welcomed these important industry developments and published two in-depth blog posts about CMAF (1 and 2), detailing the numerous benefits of the specification but also pointing out that it still allowed for the use of several incompatible encryption schemes.
Of course, many other vendors providing video streaming products and solutions jumped on the CMAF bandwagon as well, with press releases announcing support for CMAF following each other in rapid succession.
All of this happened in a matter of months.
However, back then the CMAF specification was still in draft. Many of the most important choices were made for sure, but significant details needed to be worked out. So what had actually been implemented as part of HLS (the specification barely mentioned CMAF at the time) and what were the different products and solutions claiming support for CMAF exactly generating?
Not until the beginning of last year, on January 17th to be precise, was the CMAF specification published officially. A few months later we released the 1.8.5 GA version of our products, including full CMAF support for both MPEG-DASH and Apple HLS. But not only that, we also provided the official CMAF conformance stream to MPEG that summer, and it has been freely available for both testing purposes and understanding of the standard since (the link points to a publicly accessible mirror).
This means any concerns regarding the conformance of your content can be cross-checked using the conformance streams available as well as the fully published specification.
What is CMAF conformance?
When looking at the official CMAF specification (which isn’t freely available unfortunately), three conformance points can be identified: track format, media specific constraints and media profiles.
- Track format is defined in clause 7 of the specification. It details how the different CMAF media objects, such as CMAF tracks, segments, fragments and chunks should be formatted. The track format is based on fragmented MP4 with some constraints on the boxes that can be used, and how they can be used. In addition, it defines the FourCC brands to signal CMAF media objects and how these objects can be grouped. The grouping results in the overall presentation on the highest level, which consists of selection sets, which in turn each consist of switching sets that group CMAF tracks. Switching sets are sets of tracks that contain different representations of the same content that a player can seamlessly switch between, whereas selection sets group together all switching sets of the same media type (e.g., audio, video or text).
- Media and encryption constraints are defined in clauses 8, 9 and 10. A prime example of these constraints is that content should only be encrypted according to schemes from the 3rd Edition Common Encryption (CENC) specification. Other constraints specify how audio, video and timed text should be carried, alongside the specific aspects of each media type.
- Media profiles document which configurations of things like codec, resolution and aspect ratio should be used to further enhance interoperability. CMAF defines a set of media profiles, whilst also allowing third parties to define their own. Examples from the CMAF specification itself are the
aacprofile for AAC encoded audio and thecmhdprofile for AVC encoded video.
How to test conformance
When testing for conformance the first to check is whether all tracks conform to the CMAF track format, the second is whether the media is compliant with all constraints and the last is whether all tracks conform to a specific media profile.
Tools like MP4Box.js let you inspect whether all of the mandatory boxes are present. Other important aspects to check for are whether:
- no proprietary box types are present;
- no top level box types that are not defined by CMAF;
- all ‘MovieData’ (
mdat) boxes immediately follow ‘MovieFragment’ (moof) boxes; - all tracks in the stream offer playback continuity;
- all tracks start at the same decode time;
- none of the MovieBox (
moov) boxes references any samples; - none of the tracks are multiplexed.
There also is a dedicated tool for testing CMAF conformance that is made available through DASH-IF (Industry Forum):
http://conformance.dashif.org/?cmaf=yes
Do note that unlike MP4Box this tool not only requires the packaged content to validate your stream, but also a DASH manifest (MPD). Furthermore, you will need to click the cog on the top right corner and select ‘CMAF’:
Also keep in mind that although the validator offers useful feedback in general, it is not perfect. Running our MPEG conformance stream for CMAF through it will produce positive results overall, but return some unexpected and unclear errors as well (for which we created two issues on the validator’s GitHub tracker: #479 and #480).
(The validator also reports on the ‘bandwith’ of several tracks in the stream not being signaled high enough in the MPD. However, this is not relavant to CMAF, but only to DASH, and the cause is our subpar encoding of this particular source material.)
Ready to package some real CMAF?
You may want to learn more about the tool that was used to create official MPEG conformance streams. In that case, our documentation for Unified Packager is publicly available.
Packager outputs CMAF with a fully conformant track format. You may need to re-encode your elementary streams to conform to CMAF’s media and profile specific requirements however.
If you have any questions or want more information about CMAF conformance or Unified Packager, please don’t hesitate to contact us.
