October 25, 2017
By Jan Ozer Contributing Editor
Featured Articles

Status Update: Encrypted Media Extensions and the Future of DRM

The second issue relates to the automatic generation of accessibility metadata, which could warn viewers about potential issues like strobe effects, which can trigger photosensitive epilepsy. The appeal wants to make sure this data is generated and included in the file metadata before encryption.

The final issue is the most complicated. Briefly, DRM laws are enforced by the Digital Millennium Copyright Act (DMCA), which includes a clause that lets companies sue competitors that attempt to circumvent electronic and digital copyright protection systems. The EFF asserts that this clause prevents competitors from entering the player market because they can be sued if they attempt to reverse engineer the copy protection scheme required to play the videos. The EFF is asking member companies to agree not to sue potential competitors under the DMCA for any attempt to circumvent their DRM schemes. I asked W3C’s Le Hégaret whether he thought such an agreement likely, and he pointed out that “Several past attempts in agreeing on a covenant within the W3C Membership failed.”

At the end of the day, the EFF’s objections feel like attacks on DRM itself, which they characterize as follows:

Corporations claim that DRM is necessary to fight copyright infringement online and keep consumers safe from viruses. But there’s no evidence that DRM helps fight either of those. Instead DRM helps big business stifle innovation and competition by making it easy to quash ‘unauthorized’ uses of media and technology.

The EFF has fought DRM and EME from the start, despite widespread industry acceptance. Judging from Netflix’s 54 percent penetration rate into U.S. households, most end users either don’t know about DRM or don’t care. This doesn’t mean that the EFF’s concerns are unfounded, it just means that the commercial market, both supplier and customer, has chosen to ignore them.

What Does the Appeal Mean?

The meaning of the appeal is unknown, but it’s clear that the browser and publishing industries and W3C are on roughly parallel paths that may or may not intersect. The W3C is in a tricky position; if it makes EME too onerous, the industry might simply ignore it. As Berners-Lee stated in his “On EME in HTML5” post:

If the [W3C] made a Decree that there would be No More DRM in fact nothing would change. Because W3C does not have any power to forbid anything. W3C is not the US Congress, or WIPO [World Intellectual Property Organization], or a court. It would perhaps have shortened the debate. But we would have been distracted from important things which need thought and action on other issues.

Berners-Lee is taking the practical position that it’s better to find a reasonable consensus position than to push for provisions that major players are likely to find offensive—that a spec considered flawed by some, but actually followed by the industry, is better than a pure spec that the industry ignores.

So, that’s the tempest in a teapot raging within the standards body. What’s particularly frustrating for actual users is that none of these issues are resolving the significant implementation challenges imposed by EME.

What Major Challenges Does EME Create?

I spoke with Christopher Levy, CEO of DRM provider BuyDRM, regarding how EME impacted content providers using DRM. He described two areas—technical complexity and storage costs.

Regarding technical complexity—Before EME, some customers could use a single DRM technology and set of encrypted files to serve the bulk of their target users. For example, Smooth Streaming content encrypted with PlayReady could play on the Mac and Windows computers via the Silverlight plugin, and on iOS and Android via apps. Smooth Streaming with PlayReady was also widely supported on OTT devices (excepting Apple TV, of course), smart TVs, and gaming platforms.

According to Levy, today, many BuyDRM customers have to produce three sets of files: one in HLS format protected with FairPlay, one in Smooth Streaming format with PlayReady for legacy devices, and a set of DASH encoded files with EME and PlayReady and Widevine DRM for browsers, OTT boxes, and smart TVs.

From a complexity perspective, content providers now need encoders than can package and encrypt into three formats/DRMs rather than one, and a player, players, or apps capable of decrypting and playing these formats. From a storage perspective, content publishers now need to store three times the number of files at the edge, which triples their storage costs.

What’s Available to Minimize These Issues?

In the short term, Levy reports that many customers are packaging and encrypting on-the-fly via servers like the Wowza Streaming Engine, Nimble Streamer, or via BuyDRM’s own recently announced KeyOS MultiPack Server (see Figure 2). Multiple content delivery networks like Akamai also provide this service, as do multiple products, like AWS Elemental’s Delta product.

Figure 2. BuyDRM announced the KeyOS MultiPack Server real time packager at IBC.

As shown in Figure 3, Wowza Streaming Engine supports multiple suppliers, including castLabs’ DRMtoday service, which is not shown in the picture. Obviously, implementing real-time packaging with the Wowza Streaming Engine is simplified if your DRM vendor is directly supported.

Figure 3. Packaging and encrypting on-the-fly with the Wowza Streaming Engine

While on-the-fly packaging and encryption (also called dynamic packaging) does add some technical complexity and cost, it could reduce storage costs by two-thirds. (Note that we discussed multiple approaches to dynamic packaging in a December 2016 article, “Containing Costs: How Publishers Can Save Money on ABR Encoding.")

What About CMAF?

CMAF is the Common Media Application Format. By way of background, HLS originally used only MPEG-2 transport stream segments, while Smooth Streaming and DASH used fragmented MP4 files. For this reason, even with common encryption, publishers needed at least two sets of files to deliver to their multiple targets.

CMAF is a specification jointly authored by Apple and Microsoft that uses fragmented MP4 files. In 2016, Apple announced that HLS would support CMAF. The problem is that CMAF also enables two incompatible common encryption modes: cipher block chaining (CBC) and counter mode (CTR). CBC is supported by Apple’s FairPlay and Google Widevine, but not by Microsoft PlayReady, while CTR is supported by Widevine and PlayReady, but not FairPlay. So you still can’t create one set of encrypted files that will play on all major platforms.

Basically, it’s a stare-down between Microsoft and Apple to see who blinks first—Microsoft to incorporate CBC or Apple to support CTR. There have been multiple reports that Microsoft has already blinked, but I couldn’t confirm this directly with Microsoft.

Even if Microsoft or Apple does blink, it will take a while for many publishers to feel comfortable delivering one data set to all targets, particularly those who are switching HLS from MPEG2 Transport stream fragments to fragmented MP4, which may not be compatible with older, but still relevant, targets platforms. Obviously, if you don’t need DRM, the CBC/CTR issue is irrelevant, but you still have the same concerns about backward compatibility with HLS delivered via fMP4.

At the moment, all we can report is that the EME standard is stuck in the standards bodies, though that should be resolved pretty quickly. At the implementation level, we’re getting closer to that holy grail of a single encrypted format for universal distribution, but for the time being, that appears to be a ways off.

[This article appears in the October 2017 issue of Streaming Media Magazine as "Status Update: Encrypted Media Extensions."]