Or why you won’t get 4K quality on Netflix content using Chrome anytime soon.
I’ve tracked CMAF development before [1], and how the whole industry went through so much effort into creating a common format which would be compatible with every single device out there. Yes, manifests would be different between HLS and DASH, but the underlying streamed content would be shared between all devices. In order for people to understand how we got that far, we need to understand that it took Microsoft’s willingness to allow applications and devices using Playready 3 or below to become incompatible with content encrypted using Playready 4, which hasn’t been the case until now, unless you’d require additional security levels.
Let’s just summarise the current universal ABR streaming format using CMAF, from a number of perspectives. First, containers and encryption modes.
When Microsoft moved into the AES-CBCS train, it created the opportunity to align every single content available on the planet through one single file format: an fMP4 file encrypted using AES-CBCS. And everyone was happy, because the other end of the problem was thought to be solved long ago: the actual codecs to be used. In fact, all the content available 3 years ago on the western hemisphere was encoded using the same video codecs: H.264 and H.265, being China’s AVS the sole exception.
Then, on Jan 24th, 2017, some user asked Google’s Chromium development team to support H.265 on the Chrome browser and the answer was astounding:
Thanks for your request. Sorry, we have no plans to support HEVC in Chrome, here’s a non-exhaustive list of reasons:
– Usage is ~0% on the web (per internal metrics). As such it does not justify the increased security surface.
– We try to maintain parity in ability between all Chrome variants (desktop, mobile, CrOS), so would need to provide a software decoder for platforms without a device based decoder; this has unknown licensing among multiple competing bodies.
– Edge is the only browser with HEVC support today, but still only when capable hardware is present; I.e. they do not provide a software decoder. Firefox has no plans to support HEVC. Apple has not commented, yet they don’t even provide OS support for HEVC.
Well, let’s look at it from a 2017’s perspective:
- 4K content was already being offered by Netflix and cable/IPTV operators, as a major new selling point. Yes, it was not available on the Web, because no browser would support 4K content due to lack of H.265 support.
- Chromecast Ultra was launched a year earlier, supporting H.265, and it was also the first chrome cast device to support VP9. Earlier models have no support for either codecs.
- Apple was still not supporting H.265. This was factually true on January 2017, but not after October, as Apple announced full support for H.265 up to 4K for it on all Apple devices receiving software updates.
At a latter stage, on the same response, Google recommended the usage of VP9, which was nothing but adding insult to injury:
- There was ZERO content encoded with VP9 available on the web outside of Google’s Youtube.
- There was little support for hardware support for VP9 decoding on already deployed hardware
- No other browser than Chrome was supporting VP9 (other than Firefox, which was workings as a branch of Google’s world domination effort).
- Never mind the fact that VP9 is not a competitor against H.265, requiring 30% more bandwidth to achieve the same quality levels.
So, three years ago, the rationale to support H.265 was sketchy to say the least. Maintaining it for the next three years can only be explained if Google is simply bullying the industry into submission and usage of its own VP9 codec.
The harsh reality is that H.265 is widely supported on all major device classes, only second to the all-present H264:
| H.264 | H.265 | VP9 | |
| iOS | Supported | Supported | Supported on iOS 14 |
| MacOS | Supported | Supported | Not Supported |
| Windows/Edge | Supported | Supported (1) | Supported (1) |
| Windows/Chrome | Supported | Not Supported | Supported |
| Chromecast | Supported | Supported (Ultra Devices) | Supported (Ultra Devices) |
| SmartTV | Supported | Supported (4K Devices) | Supported |
| Android | Supported | Supported (if hardware accelerated) | Supported |
| Consoles | Supported | Supported | Supported |
(1) The Jan 2020 Edge swapped edgeHTML for Blink, removing support for H.265 and adding support for VP9.
The hard true is that reality has hardly changed between end of 2017 and today: except for the Windows PC world, H.265 is omnipresent on all 4K supporting devices.
One might wonder “if VP9 is so inferior to H.265, why so many devices support it?”. The reason is simple, and again, linked to Google. YouTube only supports VP9 for 4K content. As it is Google’s Youtube paying for the extra bandwidth and storage, no one else seems to bother. For those whose such costs are relevant, such as Vimeo or OTT operators, H.265 is the only way to go. But that creates a problem…
Let’s then have a look at some content offerings, namely those from Netflix, HBO or Disney.
| Content Encoding | Browser Support | Other Devices | |
| Netflix | 4K content is only on H.265. | PC limited to 1080p, using H.264. MacOS Safari supports 4K using H.265. | 4K quality using H.265 |
| HBO | No 4K support. All content is limited to 1080p, using H.264. | 1080p using H.264 | 1080p using H.264 |
| Disney+ | 4K content is only on H.265. | Windows PC is limited to 720p, using H.264. Safari on MacOS supports 4K using H.265 | The other few devices classes allow 4K quality using H.265. |
This is where the Windows user gets screwed. Before December 2019 it would be possible for a Windows user to get 4K Disney+ content. Then Microsoft switched the engine used on EDGE from edgeHTML to Blink, and along with it any support for H.265. Never mind the fact Windows actually supports H.265 through a downloadable library, but Chrome prevents the user from taking advantage of the underlying OS’s features. Google took the option away from the user, and in the way pushes its own agenda, through VP9.
Where does all this leaves the industry ?
So, by using the enormous user base of both Chrome and Firefox, it took the PC OTT market by ransom: use our codec, or be left out of quality OTT
The original plan was simple:
- one single container: fMP4
- one single encryption: CENC with AES-CBCS
- one single video codec for resolutions up to 1080p: H.264
- one single video codec for all resolutions, including 4K, with reduced bitrate: H.265
This plan was making everyone happy: DRMs would still be able to be freely chosen. Apple and Microsoft each took their way (although Microsoft did concede a bit). Users were capable of taking advantage of the best possible video quality, at the lowest possible bitrate. Operators were capable of using one single streaming protocol for both VOD and live streaming.
But apparently all that left Google out, and Google didn’t seem happy. So, by using the enormous user base of both Chrome and Firefox, which exceeds 70%, it took the PC OTT market for ransom: use our codec, or be left out of quality OTT.
Fortunately for Netflix, Netflix’s usage pattern is no longer browser based. Users no longer use laptops as the main device to consume content, relying now on big screen TVs, either through the usage of the payTV STB, or directly on the SmartTV’s application, and there, H.265 is omnipresent. It does leave the PC browser user left with low quality, higher-than-necessary bitrate content.
Where does this leave the OTT and PayTV operator?
Well, other than the uncomfortable position that an device class on the overall portfolio isn’t supporting all the features of all the others, and unhappy users due to the lack of topmost quality on the browser, there’s little else to worry about.
This is due to the lack of market alternative, and parallel problems which drift around the browser. Operators simply don’t need to care, as the problems they’re facing are shared by all others. Even if a drive to get an edge would entice a new market entrant to offer both H.265 and VP9, it would mean a 60% streaming and storage cost increase compared with the current market offerings, making it uneconomical. So, there are no risks.
In parallel, Google doesn’t have a relevant competitive offering on the OTT market. Google Play Movies & TV doesn’t seem to be threatening anyone’s business, and in fact it creates a problem for Google: the same way Google controls the PC Web Browser, Apple controls a third of the mobile market, the most lucrative third, and on that third there’s no native VP9 support, so it must either use H.265 for 4K content, or let go the high ARPU iOS market. Google must decide which of them it really want’s: the codec or the OTT market, but it can’t have both, now.
The PC Browser
Then, the PC Browser market has enough problems on its own. Due to its open nature, is quite difficult to achieve the same level of DRM security you can achieve on a Native App running on a closed platform. The PC Browser is riddled with security issues. Contrary to the PayTV STB, which operators, chipset and security vendors spent years hardening, which ensures that the encrypted video it never made available, even at PCB trace level, on a PC things are much different. To start with, every single PC is by definition rooted. This means that a user can always take control of operative system, including the memory space, and run whatever application it chooses. Then, the video path goes through a number of different components from different vendors: the CPU, RAM, motherboard and GPU, each from different vendors and having different drivers. And although most of those software components are signed by Microsoft, it only does it in a way that are not tampered after being created by the vendor.
Summing up, a Play Ready 3 with Security Level 3000 or a Widevine L1 license running on a browser doesn’t offer nowhere near the same level of security than an payTV operator STB running the same security levels.
Recognising this, content providers such as Warner or Disney, don’t allow high valued content, such as 4K, HDR or day one blockbusters, to be offered on PC browsers, limiting it to lower resolutions, often not higher than 720p.
The MacOS browser
On the Apple side of things, really is a bit different. To start with, Apple rules the vertical ecosystem: hardware, operative system, drivers, browser, DRM and content, all is controlled by Apple, at least to some extent. This allows a MacOS user to technically be capable of streaming of 4K HDR within a MacOS Safari, and in fact, Netflix and Disney+ take full advantage of those capabilities, allow users to stream 4K HDR content. Not that Apple’s FairPlay Streaming DRM offers significantly more features than those from Playready 3 or 4, or Widevine level 1, but the fact that Apple controls the entire ecosystem, entitles content providers to feel secure enough not to place restrictions on such usage.
What lies ahead
In the medium term, a new Google sponsored codec is appearing: AV1. Contrary to VP9, AV1 was designed from the beginning as a industry-wide effort to evolve H.265, promising a 30% compression performance improvement compared with H.265 which is an extremely significant step. Competition from the MPEG ISO group will also be appearing in the form of VVC (Versatile Video Codec). However, VVC is now only arriving, where only now the reference codec were made available, and compression performance is still to be proven.
Choosing between those two codecs will end up on how the industries major players will move. Google will decidedly support AV1, but the decision from Apple is still likely years away.
AV1 has one distinct advantage: by arriving much sooner, it allowed hardware implementations to start appearing on the market from the chipset’s major manufacturers. However, given the huge installed base of older devices not supporting it, it will take years before it can expect wide adoption. Whether the future is H.264/H.265/AV1 , or H.264/H.265/VVC is not something we can foresee at this moment.