You have to look at it in context. The alternative to HTML5 EME is not un-DRMed content but rather the entire commercial video industry mandating non-web technology. That leads to vendor lock-in, security problems and increases the barriers to entry for everyone involved in video:
* Cool device? Now you need to convince (read pay) Adobe or Microsoft to port Flash/Silverlight to it or develop a native app and make it non-horrible e.g. for Netflix users to find and use.
* Create a new video codec? You have to add support to Flash/Silverlight before most people can use it
* Want to put video online? If any of it's for sale, you have to build out a full Flash/Silverlight stack to support it.
That's expensive and as we've seen it's a huge security hazard and generally holds technology back – e.g. neither Flash nor Silverlight play back H.264 anywhere near as efficiently as the native OS despite having years to add decent hardware acceleration.
From the perspective of a web-focused company like Google, that's a lot of downside with no advantage. Even Microsoft and Adobe aren't interested in doing much with Flash and Silverlight and they're expensive to keep alive as niche media playback platforms. That's why we ended up with EME in the first place – it allows every single component except for the actual decryption to use the standard web stack.
If Firefox shipped Daala tomorrow, YouTube could start serving it next week rather than wait a year or two for it to go through the release cycle at Adobe/Microsoft.
If a video site needs to support both open and encumbered media (a given for all but a few markets) this allows them to keep every single part the same except for the encryption stage without a degraded or inconsistent user experience.
DRM won't go away overnight, so we're going to see sites selling both and making that process as easy as possible will hasten the time where we can see an actual market response to restrictions – both from consumers being less willing to pay full price for encumbered content and from sites who are tired of DRM licensing eating into their revenue. If that's as simple as unchecking the “Use EME” box, you'll see a lot more willingness to experiment that you will if it's “Change our video production and serving pipeline away from the expensive Flash Media Server setup we already paid for”.
> * Cool device? Now you need to convince (read pay) Adobe or Microsoft to port Flash/Silverlight to it or develop a native app and make it non-horrible e.g. for Netflix users to find and use.
This is still true with EME. EME is just an API, you still need the closed-source proprietary DRM module itself, the CDM. You would need to convince/pay one of the very short list of such modules to port it to your device, and you would need to do so with a module that the content creators support.
The same is true for the other things in that list. EME simply does not even try to solve those problems - it just provides a standard HTML5 API to what remains a closed-source proprietary DRM module. There are very few companies with such modules - Adobe, Microsoft, and Google are the prominent ones. Without partnering with at least one of those, you can't bring DRM'd content using EME to a new device.
The difference is that you're talking about something which is MUCH smaller: someone can port the CDM to a new platform in far less time than it'd take for a complex platform like Flash or Silverlight because all you're dealing with is the DRM, not things like networking, display, sound, hardware accelerated video decoding, OpenGL, etc. Both Flash and Silverlight are to a first approximation as complicated at the entire web stack and almost none of that functionality is needed for a simple video player.
Yes, it sucks that it's proprietary but since consumers don't show any sign of refusing to buy DRMed content it makes sense to restrict the footprint as much as possible rather than letting the requirement for DRM drive your entire platform.
> DRM in HTML5 means that you don't need Flash/Silverlight to play Netflix, etc. Which means that you can support video more easily.
You still need a closed-source DRM module, as a replacement for Flash or Silverlight. It doesn't make it any easier in that respect. It does provide a standard API between such DRM modules, though.
But yes, this is good for Google, as it does own one such DRM module (Widevine). So Google can push its own DRM and does not need to rely on third parties like Flash or Silverlight.
Yes, you still need the closed module - but all it does is decoding, which means that it's much smaller than Flash/Silverlight.
I wish the video companies didn't insist on it, but if we need to have something to keep them happy, I'd rather it was a simple decoder than a whole plugin runtime.
Except that VP9 isn't patent-free. MPEG LA and other patent holders simply haven't bothered to flex their muscles because VP9 adoption is pretty much non-existant.
That's why I much prefer H.265. It is a defacto standard.
> In March 2013, MPEG LA announced that it had dropped its effort to form a VP8 patent pool after reaching an agreement with Google to license the patents that it alleges "may be essential" for VP8 implementation, and granted Google the right to sub-license these patents to any third-party user of VP8 or VP9.[26][27] This deal has cleared the way for possible MPEG standardisation as its royalty-free internet video codec, after Google submitted VP8 to the MPEG committee in January 2013.
I'm not sure I understand what you mean. MPEG LA sue Google for a technology invented/bought(and patented) by Google? Is that it? I think I need more details to understand what you truly mean.
* Cool device? Now you need to convince (read pay) Adobe or Microsoft to port Flash/Silverlight to it or develop a native app and make it non-horrible e.g. for Netflix users to find and use. * Create a new video codec? You have to add support to Flash/Silverlight before most people can use it * Want to put video online? If any of it's for sale, you have to build out a full Flash/Silverlight stack to support it.
That's expensive and as we've seen it's a huge security hazard and generally holds technology back – e.g. neither Flash nor Silverlight play back H.264 anywhere near as efficiently as the native OS despite having years to add decent hardware acceleration.
From the perspective of a web-focused company like Google, that's a lot of downside with no advantage. Even Microsoft and Adobe aren't interested in doing much with Flash and Silverlight and they're expensive to keep alive as niche media playback platforms. That's why we ended up with EME in the first place – it allows every single component except for the actual decryption to use the standard web stack.
If Firefox shipped Daala tomorrow, YouTube could start serving it next week rather than wait a year or two for it to go through the release cycle at Adobe/Microsoft.
If a video site needs to support both open and encumbered media (a given for all but a few markets) this allows them to keep every single part the same except for the encryption stage without a degraded or inconsistent user experience.
DRM won't go away overnight, so we're going to see sites selling both and making that process as easy as possible will hasten the time where we can see an actual market response to restrictions – both from consumers being less willing to pay full price for encumbered content and from sites who are tired of DRM licensing eating into their revenue. If that's as simple as unchecking the “Use EME” box, you'll see a lot more willingness to experiment that you will if it's “Change our video production and serving pipeline away from the expensive Flash Media Server setup we already paid for”.