tl;dr; For content that doesn’t require DRM, we’re there. If you need DRM there’s still some work ahead.
At WWDC 2016 Apple had some big news for the video streaming community. They announced two big changes that move us closer to a world where media files can truly be shared. Announcement one was that the HLS (HTTP Live Streaming) specification would be expanded to allow for use of fMP4 (fragmented MP4) media segments. The second announcement was that FairPlay would support fMP4 segments that are encrypted with CENC. Unfortunately as is often the case, the devil is in the details.
Let’s start with the good news. fMP4 support in HLS means that content libraries that do not require DRM can use a single set of content to serve most (if not all) clients. You will need an MPEG-DASH manifest and an HLS manifest, but the segments referenced by those manifests can be shared. This is huge! This has a major impact on the cache-ability of assets and on storage costs for media libraries. The open question here is what versions of iOS will support this new version of HLS? Will there be an update to old versions of iOS or will this be an iOS 10+ feature?
Now for the news that turned out to be a pretty big letdown. Apple announced “Sample encryption uses part of ISO/IEC 23001:7 2016” (that specification is for Common Encryption, a draft version can be obtained from mpeg). The next line in the slide says “MPEG standard—“Common Encryption”, this is looking great. However that was followed by “‘cbcs’ mode” which made it clear something fishy was going on. The language they used should also have made it clear something was up “uses part of” is not a good sign for implementing a standard.
To understand what is going on here we need to understand the CENC spec and the new HLS spec a bit better. The new versions of the CENC spec define 4 separate protection schemes for content. The 4 protection schemes defined in section 4.2 of that specification are ‘cenc’, ‘cbc1’, ‘cens’, and ‘cbcs’ (yes, one of the schemes has the same name as the overall spec). Of these 4 protection schemes only the first, cenc, is required for implementors to support. The other three are optional.
Now we need to better understand what was added to HLS. The new spec in section 18.104.22.168 says “fMP4 Media Segments are encrypted using the ‘cbcs’ scheme of Common Encryption”. They’ve added support for the optional ‘cbcs’ protection scheme, without adding support for CENC spec required ‘cenc’ protection scheme. This means that if you need to protect your content with DRM you cannot use the same fMP4 fragments for FairPlay as you use for PlayReady or WideVine.
Why would Apple choose to “use part of” the CENC spec and not implement the one required protection scheme? We don’t know all of the answers, but one key point that Roger Pantos drove home in one of his presentations “Content Protection for HTTP Live Streaming” was that battery life is king. He even said “every choice we made was predicated on giving you good battery life”. So what does the ‘cbcs’ protection scheme have to do with good battery life?
Of the 4 protection schemes defined in CENC the first two (‘cenc’ and ‘cbc1’) are Full Sample Encryption. As the name implies these protection schemes encrypt the entirety of the protected segment. The two newer protection schemes (‘cens’ and ‘cbcs’) use Subsample Encryption. In subsample encryption only a portion of the protected segment is encrypted. The spec says “Each Subsample SHALL have an unprotected part followed by a protected part”, so about half of the segment ends up being encrypted. This means that there is less work that needs to be done on the client as only about half as much data needs to be decrypted. In addition the ‘cbcs’ protection scheme treats each subsample as an independent encrypted block, this means that subsamples can be decrypted in parallel allowing for faster decryption of streams.
The ‘cbcs’ protection scheme is a great approach allowing for faster and more efficient protection of content, however the lack of support for ‘cenc’ within FairPlay means that DRM protected content must still be fragmented. We’ve come much closer to an ecosystem where we can use a single set of content files to deliver high quality protected video content, but we’re not quite there yet.