HTML5 Video at Netflix | Hacker News Reader

HTML5 Video at Netflix

techblog.netflix.com

176 pointsLightning127 comments

Writing a technical article about the standards process around web DRM without even obliquely addressing any of the criticism of it seems like a strange choice to me. Almost everything in this article was already publicly known; what I'd like to have seen was an actual rebuttal of the criticisms of, among others, Ian Hickson, so as to move the standards conversation forward.

I don't think it's in their interest to even acknowledge there's an issue.

Probably not, but then why say anything at all? The omission is conspicuous.

Companies like Netflix are stuck between a rock and a hard place. They'd sooner do away with DRM as it adds significant cost and complexity yet only serves to inconvenience their users. However they're forced into using DRM by the content owners who argue that such measure are required to protect their content.

This is why their position on DRM is often left unspoken, they can't publicly discredit because they need the studios on their side. But equally it's hard to address the criticisms if they also agree with such criticisms. So it's easier to just avoid being drawn into the argument to begin with.

If what you say is true, since they have started producing their own content (House of Cards), maybe they could experimentally distribute those shows (or at least some episodes) without DRM and use the results as a proof to convince studios that DRM is unnecessary and pointless.

The experiment's already been done. House of Cards was only released with web DRM, and yet it was available via the usual unauthorised channels almost immediately. Even when no non-DRM alternatives are available, DRM is still useless in preventing dissemination.

Maybe I'm misreading this but isn't DrJokepu saying to release the show without DRM, not with? If

> House of Cards was only released with web DRM

then how has the experiment been performed? Or did you mean to say the show was released without web DRM?

OK, the experiment isn't exactly the same, but it tests the same hypothesis: that the presence of DRM does not affect the dissemination of the content.

In fact, I'm not sure that performing DrJokepu's experiment as stated would prove anything: releasing episodes of HoC without DRM would have little effect, as they have been copied despite not having been made available without DRM.

My idea was that if it can be shown that piracy levels are about the same with and without DRM an argument could be made that perhaps investing in DRM is a waste of time and money.

It also sort of depends on the scale of copying. Having easily available "download movie from netflix" versus "download movie from shady piracy website". Obviously, the analog hole is always there, so there will always be that vulnerability.

Are you under the impression that anyone had ever in the history of anything proposed the hypothesis that lack of DRM defeats piracy?

The hypothesis is that it does just as good (really bad) job of preventing it while encumbering legitimate customers less.

I'm pretty sure Netflix doesn't completely own the rights to HoC - MRC[1] does.

[1] http://en.wikipedia.org/wiki/Media_Rights_Capital

While this is probably true, surely their special role in the financing and distribution of the show would have allowed Netflix to negotiate such exploitation rights if they wanted to.

The main function of DRM is not to prevent copying; it's to provide content rightsholders with a legal hook on which to hang people who make/distribute/use unauthorized copies.

Why should they address criticisms of DRM? They've already decided that they need DRM (or rather, their contracts require it). So, why should they spend the time debating the same things over and over again?

From their perspective, the DRM question isn't if, it's how. So, that's what their article is about.

But they talk about the "how" (the EME) as a done deal, when they don't seem to be, given Mozilla's opposition; more people will have to be convinced for this to actually work. Besides, everyone knows their proposed "how" already. A blog post that just says want to move to HTML5 delivery using this set of extensions they've already publicly supported for this purpose doesn't add much to the discussion.

They need DRM due to the reality of their relationship with Hollywood. There's nothing to debate. Either they get DRM support in HTML5 and switch to it, or they continue to use plugins and apps.

I don't see a problem with that. No DRM in HTML5. People are demanding less horrible web standards (flash must die!), and we watch the tension build until something catastrophically breaks. Something HAS to break.

Aren't you willing to play chicken? I am.

They are a single company operating in a single market... they don't offer to sell me any product and i have no interest in what they have... i and people like me make up the vast vast vast majority of the the internets population.

So we don't even get an opportunity to play chicken... google and netflix will break the net and shove this shit down our throat regardless. Why should we the vast majority of the Internet give a shit about their precious hollywood contracts?

I am willing to play chicken. Flash must die, and more than that, the standards should make no additional allowances for broken behavior, such as allowing websites to discriminate between Platform A and Platform B.

In practice, as long as Javascript remains in its present form, they will be able to effect this sort of discrimination, but the W3C doesn't need to actively promote brokenness.

They have not moved away from plugins, they merely replaced 3rd party plugin with their own.

Their HTML5 solution relies on their own closed browser-specific plug-in (EME CDM) and browser vendors that don't have Netflix's license are unable (both technically and legally in US) to use it.

So they continue to use plugin that runs their native code. The only change is that they've taken away leverage that NPAPI gave Microsoft and browser vendors.

I honestly don't understand DRM in html specs. Most people use open source browsers. To crack the "DRM" all you would need to do is open up the source code and slightly modify it. DRM only works when either the client side code hasn't been cracked or when the server side requires clients to log in. The first is impossible with open source, and the second is already a part of html.

Which indeed is why the implementations aren't going to be open source. The last I saw of the design, the intention was to put the entirety of decryption, decode, and display into a binary browser plugin and the HTML5 parts were only the bare minimum needed to push encrypted data to said plugin.

Yes, this is precisely the idea of the second of the three technologies mentioned (encrypted media extensions) - let HTML5 video interface with a separate opaque binary plugin that implements DRM.

Of course such binary plugins will be browser- and OS-specific, so this is going to result in a lot of problems, and goes against the spirit of the web.

The DRM doesn't happen in the browser, it happens either in the OS or on a hardware component. Encrypted Media Extension just provides a way to communication with the DRM component. It's up to the web page to choose what type of DRM they accept. Expect most to require DRM on the hardware.

This means "premium" video is going to be fragmented. Big companies like Apple, Samsung, Microsoft will get it, open source operating systems and DIY devices will not.

> This means "premium" video is going to be fragmented. Big companies like Apple, Samsung, Microsoft will get it, open source operating systems and DIY devices will not.

People said the same about DVD and bluray DRM, yet they've been cracked and open source drivers distributed. Though it's sad that it ever had to come to that.

cracked and work's out of the box are two different things... practically and legally.

i dont care about netflix... like the vast majority of the internet, they dont even operate in my market. yet their greed is going to fragment the internet that i make a living from... all they are doing is ramming a new version of shitty proprietary plugins/binary blobs down our throats.

> cracked and work's out of the box are two different things... practically and legally.

libdvdcss works out of the box and is completely legal in Europe. It's the Americans that stand to lose more by imposing DRM extensions on the internet. At least if they're part of HTML, the technology can be reverse engineered and made cross-platform. With the current mess we're stuck with having to run Silverlight DRM extensions in WINE. So as much as I hate DRM, I'd sooner see it part of an open and cross platform spec than have content locked to specific software that only runs on specific platforms.

> open and cross platform

Fail to see how this is anymore open and cross platform then NPAPI.

> content locked to specific software that only runs on specific platforms.

that is exactly what this delivers.

The issue still stands - you could easily engineer a component that just pipes the output directly to disk instead of displaying it.

That depends.

If the DRM black-box is talking directly to the display hardware, you might not be able to do this. Of course then your video will also not be subject to things like CSS opacity, clips, rounded corners, etc, etc...

DRM isn't in html specs. This is just a standardized interface to a vendor-supplied DRM component.

>Most people use open source browsers

Technically not true.

Depends which stats you look at. Some say it is true other not so much.

https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Su...

Chrome, Safari, and soon Opera are mostly open source, but not totally.

The distinction is especially important in case of video. Only Google's own build of Chrome has license for H.264 and MP3 codecs and Netflix DRM plugin, and Chromium doesn't.

I think if your intention is to encrypt your video content then you really have no business being on the web in the first place. Just build a native app and do whatever you want, and stop trying to bend open standards to be compatible with your business.

They're are many legit reasons to encrypt video (CCTV, video chats, etc). The web is the platform of the near future, I'd rather support this stuff natively than need multiple closed source desktop or mobile apps.

this isn't about encrypting it to prevent others from seeing it. It's about encrypting it so the viewer can't control it.

Encryption != DRM. All of that stuff you can do now with SSL. No one cares about video streams over SSL. It's what happens after the SSL layer that matters.

Indeed, but you're not going far enough. I never buy from any website that uses HTTPS! The idiots running them don't appreciate the open way the web is meant to be used.

Or, people get to use the web however they want without rigid "open everything" extremism. Netflix is the best business model on the internet right now: you pay them $X a month, get great content, everyone gets paid. DRM makes that possible. I find it far preferable to the advertising/spyware-based monetization model, which seems to be the only other viable business model for content on the internet. The internet standards should be flexible enough to accommodate both and let consumers choose.

> DRM makes that possible

O'RLY? That seems like a big jump of logic there. It's just as possible that with zero DRM they'd still do fine given playing back a movie in Netflix is far nicer than searching for the movie on some ad-ridden virus infested download site and then waiting several minutes to hours for it to be available.

So the content producers are in the clear, right up until someone comes up with a user-friendly interface for doing Netflix -> DVD rips.

The point of DRM isn't to make it impossible for some people to copy the content. It's to make it inconvenient for ordinary people to copy the content. That's what the big problem with Napster was (after all, people have been copying content on Usenet since the dawn of time).

With the current scheme house of cards was outside netflix within a week (if not the same day) So content producers are already doomed, why saddle html5 with DRM and binary blobs?

Well Netflix has less of an incentive for DRM on their own content, since they don't have any DVD/Blu-Ray sales to protect. But to the extent that unencrypted streams make it easier for unsophisticated users to rip DVDs from streams, it's a relevant consideration for the big media companies that offer content on Netflix.

In the long run, content producers will survive because the general purpose PC will be marginalized as a platform. The future is not people watching torrent-ed rips of movies on their laptops, it's people watching Netflix and similar services on their Apple TVs and iPads. At that point it doesn't matter if the content is encrypted or not, since it won't be convenient for your typical user to watch a ripped copy.

You're quite the prognosticator.

I would argue that the content producers will survive in spite of the fact that they lose the battle to create an entirely hands off encrypted media path from the website to your viewing device.

They will survive because they make their content easy to buy. They will survive /well/ if they make their content easy to buy and to license.

> So the content producers are in the clear, right up until someone comes up with a user-friendly interface for doing Netflix -> DVD rips.

Such programs are already available and are quite user-friendly.

I love Netflix being a separate app on my mobile devices. Going through the browser seems hacky.

What if Apple decides to ban Netflix from the store due to a perceived slight, or because Apple decides to compete directly?

Switch to an Android phone?

Apple won't support this browser encryption extension scheme on iDevices in any case.

Then it's a very good thing so people understand that you cannot rely on a platform where one company has all the power on what can run and what can't. Maybe it'd spring see nice anti-competitive trials. Results being irrelevant, as long as people understand that locked platforms are bad.

Native player supports AES 128 encrypted video.

Earlier iOS supports encrypted chunks, iOS 6 and up supports encryption of audio and video samples as well.

The HTML5 based DRM would require a binary blob for the browser so that's not likely to happen for the iPad/iPhone anyway.

"We will remove this last remaining browser plugin as soon as WebCrypto is available directly in the Chrome browser. At that point, we can begin testing our new HTML5 video player on Windows and OS X." - What do they have against linux?

Probably nothing, except statistically nobody uses Linux on the desktop, so it's not a priority.

Maybe not on the desktop, but there are plenty of people using it as a media center OS. Enough that someone went to the trouble of rolling a custom Wine distribution to get Silverlight + Firefox accessing Netflix.

At this point it's just kind of silly to exclude Linux, especially when all the heavy lifting is already done; Chrome OS _is_ Linux, and I believe the Roku devices are Linux-based as well.

The reasons Netflix might have to exclude Linux are not unique to Netflix, but somehow Amazon and Hulu - both Flash-based, of course - manage to support these customers.

I think in the short term Chrome will be a prereq to watch Netflix (fallback to Silverlight in other browsers). In the long term DRM requirements are going to change and hardware-level DRM is going to be mandatory. Speculation.

From Valve's Steam stats Linux has been between 2-2.5% in its first opening few months where as OSX is only 3.5%. If a Mac port is assumed, one might wonder if that should be extended to Linux. and it's not impossible we'll see Linux over take Mac on Steam this year as it stabilizes, gets more games and more people sign up.

You should try xbmcbuntu on a htpc sometime.

"...and we've just started using this technology on the Samsung ARM-Based Chromebook. Our player on this Chromebook device uses the Media Source Extensions and Encrypted Media Extensions to adaptively stream protected content."

I'm not an expert on Chrome OS internals but it seems to me that being a GNU/Linux derivative with an X Server, it's not much of a jump to say the Linux version is being developed and tested first.

Edit to clarify: I'm guessing the development is being done on a Linux machine rather than directly on a Chromebook.

chromebook has hardware based drm.

ChromeOS does not use X, though X can run on the devices.

Chromium is actually providing it's own compositor and windowing system.

The plugin they are getting rid of the is the Chrome-only Pepper API based plugin that for some reason is unavailable on the current Samsung ARM Chromebook.

The blob that you compile against the pepper api is native code. So they would need to recompile the blob for ARM as well as x86.

Whether or not this is actually hard for their codebase, I have no idea.

This is incorrect: the default UI runs on X.

The cardinality of the intersection of the set of people running Linux on a desktop/media center and the that of people dying to watch DRM'd content is likely small enough to be easily ignored.

They shouldn't be boasting, rather they should be ashamed about adding DRM to the HTML standard. And they present it as if it's a great achievement. Really unpleasant, if not even disgusting.

And if someone here claims that Netflix don't really like it, but just oblige the crooked studios who push for DRM, what are they excited about then?

Because technical challenges are interesting in their own right, even if there is a larger political backdrop?

They could say that, adding, that as a whole this is bad, and they'd rather not do it, but "no choice and etc." (no really?). But they didn't. I personally don't think that being excited about implementing an unethical thing is good.

Maybe they're excited because it means that more people can use their service (and won't have to suffer the terrible experience of Silverlight). Just a thought.

Presumably they are going to require proprietary native code running in the browser? If pure open source could actually play the streams then the DRM is pointless.

Yes, your HaikuOS box won't be able to watch Netflix, unfortunately.

I suspect you're just trying to be a smartarse, but it hides an important point. It's not that HaikuOS can't watch Netflix, but that in the platform-specific DRM world, no new system that comes along can ever be a viable desktop without the blessing of the media establishment, and that this has the effect of entrenching existing players, especially those with money and connections.

The corollary of that is that keeping illicit distribution going might be a good bet for a diverse computing future.

You suspect wrong, I want the web to work the same no matter how I access it. I'm saddened at the likely future you point out.

My apologies! In that case, I join you in sadness.

How feasible would it be, instead of encryption/decryption in the browser source code (which can be defeated easily), to do decryption and rendering in javascript, perhaps with emscripten + asm.js optimizations? That should provide a reasonable amount of security through obscurity.

The problem, as with any DRM scheme is that the plaintext is available somewhere. Figure out where the buffer is, read it via the JS console (or Pin if the browser won't cooperate) and you're done. Asm.js probably offers as much protection as a normal binary, although the niceties of the JS runtime might make developing patches to dump streams easier than in native code.

I'd definitely say it's feasible, although I'm not sure it would add much beyond what Flash/Silverlight already provide.

Can anyone please explain me the purpose of DRM used by Netflix? I mean, if you can see the movie, doesn't it mean you can screen-record it with pretty great quality? And it can be done with any of available programs out there. What's the point?

Appeasing the political class (RIAA/MPAA).

What exactly is Netflix trying to prevent by using DRM? It seems like people are happy to pay for a Netflix subscription, even more if they could stream on Linux.

They are probably trying to prevent breaking their contracts with the content providers, which, somehow, think DRM actually hinders things.

We'll see how quickly the new Netflix-only Arrested Development ends up on The Pirate Bay.

I have a Netflix subscription, but sometimes I still prefer to torrent. I can force HD, I can load proper subtitles (ones without all caps), I can fix audio or video issues (levels).

Probably about as quickly as the Netflix-only House of Cards ended up on The Pirate Bay: about 2 hours after its release.

At equal quality?

I don't know what the original quality is, but for TV, there are usually 2 or 3 release formats (excluding webrips): standard quality (about half the height/width of 720p), 720p, and 1080p. The standard quality and 720p are usually posted a few minutes after the show airs, and the 1080p usually comes a long time later. Sometimes, episodes are even posted before the show airs in your region.

But how are they doing the rips? Are they getting the original encoded stream, doing analog capture and reencoding, or what? If DRM forces them to do a less than perfect copy of the stream, that's a big win for the content producer.

Maybe through DVI? If you can watch something on a standard computer monitor you can also capture it in high-resolution RGB through the DVI port.

Right, but then you decode -> re-encode which decreases quality. At the aggressive bit-rates used for HD content online, that can be substantial. So as long as DRM forces re-encoding, content producers can say: "buy it for the best quality" and that's a win for them.

Sorry for the late response; I don't usually check threads. According to someone I asked on IRC, House of Cards apparently airs somewhere offshore (I think it was Germany), but that is where the non-webrip episodes are coming from. It also explains why there are only six different non-webrip episodes released.

BTW, the webrips are the ones that are coming from DVI or from captured + decrypted video streams.

No, they were just re-encodes to my knowledge. I have a Netflix account and I checked out one of the pirated ones just to compare. I couldn't tell a difference so they did a good job, but I'm sure the difference was there.

I'd imagine the Netflix DRM will get broken sooner or later, especially as they continue to release Netflix-only content, but the screen caps have been so good that the pressure to do so hasn't been very high I don't think.

Yeah, I know lots of people who pay for a netflix subscription and then torrent netflix available content for higher resolution/etc.

It would take about five minutes for a Napster-like browser plugin to arrive that would allow the user to trivially dump the whole movie to their hard drive. Maybe Netflix's business model could sustain that, but the content owners would have a heart attack, fearing cannibalization of their other distribution networks.

Sure, everything's all on the torrent sites anyway, but the legal scare tactics worked to scare enough people away. With Netflix-Napster, though, there'd be no way to tell the difference between a legit stream and an unauthorized rip.

Obviously copy-friendly business models are preferable, maybe even inevitable, but for now, intellectual "property" rights trumps all.

Also: Subscribe for one month, download all the catalog, stop the subscription.

You forgot 'rig up a petabyte of live storage capacity' in there somewhere.

By switching from Silverlight DRM with public interface (NPAPI) to Netflix DRM plug-in (CDM) with secret API and more restrictive licensing they're gaining ability to prevent any unapproved software from using the website.

Currently thanks to NPAPI interoperability anybody could build a browser/player that plays Netflix in ways they cannot easily control.

But with their own DRM plugin they can for example ensure that only Google-built Chrome can play Netflix and Chromium can't, so you won't be able to build your own Netflix settop box.

It's not about preventing piracy. It's about enforcing content providers' wishes on browser and OS vendors, and using W3C's name to legitimize the practice.

https://plus.google.com/107429617152575897589/posts/iPmatxBY...

Interesting; but with nothing to test, it seems like vaporware.

According to the article, it's already available on the Google Chromebook. So presumably, there are people out there capable of testing this out.

I have used it. It does work pretty well...

So Silverlight is getting EOL in 8 years. Will they keep updating it with new versions til then?

My understanding is that it has already been axed. Microsoft supports product versions for 10 years after their official release. You can expect to see bug fixes, but no new versions.

Can't the big media eco-system collaborate and develop a plug-in instead (open source, platform agnostic, an extension to HTML5 video etc)? I would rather download and install "HTML5 Premium Content Add-On" or have it pre-packaged in my browser/OS any day than have the internet itself be that much more opaque by design.

iOS, Metro, and probably Chrome OS are not going to allow a new plugin.

How about Job's famous "Thoughts on Flash"[1]

> we strongly believe that all standards pertaining to the web should be open. Rather than use Flash, Apple has adopted HTML5, CSS and JavaScript – all open standards.

Not suggesting iOS would need to support it native or in Safari (though they might choose to), they would only need to allow developers permission to have it as a dependency in their app packages (Netflix.app, BBC.app, etc). it could just be a thin layer on top of HTML5 video element, just to support DRM delivery. Why is this less desirable than it being baked into the HTML spec itself, essentially breaking the open web?

[1] http://www.apple.com/hotnews/thoughts-on-flash/

Browsers supporting all relevant W3C specs and all codecs still won't be able to play HTML5-based Netflix.

Playback relies on Netflix's proprietary Content Decryption Module that they've given to Google to bake into ChromeOS.

Netflix is replacing `<object>` + NPAPI plugin with `<video>` + Netflix CDM plugin. So their HTML5 player is as much standard as their HTML4 player was — it's merely a tag to launch a proprietary binary.

Apple would have to license Netflix's CDM plugin and bake it into the iOS in the way that ensures it's usable only in ways approved by Netflix.

There is no way to avoid that, and that's the whole point of EME spec that Netflix+Google+Microsoft pushed through W3C.

Interesting, thank you for the answers, sounds like it could be a fair compromise in that case.

Apple also used to have an open letter on their website supporting the notion that all internet standards should be royalty free. Strangely it seems to have been removed.

http://xml.coverpages.org/AppleComputerPatentStatement.html

It's explained in the second paragraph of the blog post why they no longer want to use plug-ins.

This is exactly the opposite from what they want, as it allows unapproved 3rd parties to access their website and provide user interfaces they may not like.

This is why they're moving away from public NPAPI and replacing it with a secret CDM API:

https://plus.google.com/107429617152575897589/posts/iPmatxBY...

I'm always pleased with Netflix- their product is good and so is their engineering. I'd consider them the ideal company to work for as much of their product is both cutting edge and customer facing.

Looking at the open positions, I see no internships or entry-level positions in Engineering- anyone have any advice on landing a gig there?

they have a reputation for only hiring very senior-level engineers.

It's great to see Netflix pushing for HTML 5 media encryption, it's one of the things the orignal spec for these elements lacked. Once it becomes standard across the browsers we'll hopefully see more media publishers come onboard supporting HTML 5.

Because EME makes the DRM pluggable, it's never going to be standard across browsers. Different browsers will have incompatible DRM plugins.

As i understand it, it's a standard API that the browser exposes to external processes. The browser doesn't have any DRM plugins, just EME. the decryption happens outside the browser, and any decryption modules installed on the system will be available to all browsers.

You can say it any way you want, but Apple devices will only support FairPlay (which will not be available on any non-Apple platform) and I would expect Chrome OS to only support Widevine. There will not be interoperability.

And frankly, I don't want any of that crap on my machine.

It's a binary blob loaded on-demand with hardware access, what's the worst that could happen?

No, EME is an API that the browser exposes to site-supplied JavaScript code. The JavaScript code uses EME to talk with a Content Decryption Module (CDM) whose exact characteristics (including the protocol you talk with it; EME sees byte buffers) is unspecified and out of the scope of the EME spec. The interface between the browser and the CDM is not being standardized.

The CDM is basically a new kind of proprietary component that exposes a CDM-specific protocol to the Web and that is annexed to the side of the browser. You should not assume the distribution model to be the same as with traditional plug-ins: E.g. in the case of Chrome OS, the CDM comes from Google itself.

I like how almost every single comment is a variation on "Netflix for Linux, please".

What surprises me about this is that Microsoft is actually going to support Silverlight through 10/12/2021.

Standard practice. It's really limited support. The Eeebox's video decoding hardware I bought just a few months ago isn't supported by silverlight and probably never will be, which makes watching HD streams on netflix nearly impossible. That's just going to get worse.

Pretty hilarious that almost all the comments on that page are related to native support in Linux.

I wonder how long it will take for the DRM to be broken in HTML 5...

Does it work in Linux?

Linux is only a kernel. The blog post says it runs on ChromeOS witch utilizes a Linux kernel.

I wouldn't assume so quickly that because it works on Chromebooks, it can work on Linux. Google uses a certain type of DRM for Chromebooks, and they've collaborated with Netflix for this.

Linux support?

Only if Netflix chooses to port their HTML5 DRM plug-in (CDM) to Linux and makes the CDM API available to browser vendors (the W3C spec they wrote deliberately does not have this API documented).

And this is unlikely, since Netflix and other cable companies stated they need strong DRM with OS and hardware support (which I presume is what they got in the closed version of ChromeOS).

Reply on news.ycombinator.com