3 ms·
Content decryption modules probably won't be plug-ins. > The spec gives no guarantee that a given CDM can be interoperable with all browsers. I'm not sure if
by trunnell 14y ago
Content decryption modules probably won't be plug-ins.
> The spec gives no guarantee that a given CDM can be interoperable with all browsers.
I'm not sure if the CDM is actually part of the spec. They are in the diagram for illustrative purposes. The APIs being proposed on the media element are agnostic to the type of CDM being used.
> The proposal is a step back for the openness and interoperability of the Web.
If you include video from Amazon, HBO Go, Netflix, and others in your definition of "the Web", then I disagree. This spec expands the set of applications that can be implemented in HTML5 and javascript. It doesn't immediately change the interoperability of these applications, which already have limited platform reach, but it at least opens the door for more platforms (like Linux).
- ferongr 14y ago>I'm not sure if the CDM is actually part of the spec. They are in the diagram for illustrative purposes. The APIs being proposed on the media element are agnostic to the type of CDM being used. The spec may not have specifics on the CDMs themselves but that doesn't really matter. A closed-source, platform specific CDM (e.g. one distributed with Windows containing keys for the major media distribution behemoths) is very bad for interoperability. Such kinds of CDMs will probably not find their way to GNU/Linux of BSDs. >If you include video from Amazon, HBO Go, Netflix, and others in your definition of "the Web" The Web is the platform itself, not the services offered over it in my book. Companies and business models rise and die all the time but the platform of Web is what remains behind. It should not be saddled by companies like Netflix that use it and try to influence its direction to further their interests. And there is no open door for open-source, CDMs on open-source systems without a "Protected Media Path" or similar.