Sorry, but there's an important distinction between what you said and what EME is.
EME is a spec for a communication channel between script in a web page and a browser, with the idea that the browser then talks to a DRM module. It's not a spec for a communication channel between the browser and a DRM module.
This is important, because it means that you end up with DRM modules that are tied to a particular browser.
The NPAPI plugin situation is unfortunate in all sorts of ways, but the one good thing it had going for it was that there _was_ an API that multiple browsers all implemented, such that a single plugin binary woudl work in all of them (modulo the usual bugs and incompatibilities you have when there are multiple implementors of an API).
Unfortunately, 3 of the 4 main browser vendors also happen to be DRM vendors, and were rather united in their opposition to the W3C creating a specification for the communication channel between the browser and the DRM module.
Is there any current or proposed implementation that can support W3C SMIL in the browser? A decade ago, RealPlayer was able to seamlessly edit video excerpts (defined by start::stop intervals) into a single video stream. The excerpts could have originated from different servers.
Will the new DRM formats support this use case? E.g. if I'm a paying Netflix subscriber, could I view a dynamically defined (XML or JSON) mashup of Buffy and Twilight, using only a list of start/stop edit points? The HTML5 viewer would need to pre-buffer each video clip, to make the viewed stream seamless.
Wouldn't the DRM spec have to explicitly permit MSE buffering? If Javascript could buffer the stream and send it to any destination other than a DRM-approved output device, that would defeat the DRM.
The way EME is designed, the browser is responsible for fetching the data from the network and passing it to the DRM module. This is no different with MSE, as far as I can tell; what you buffer up is the encrypted data, then pass it on to the DRM stuff.
Thanks, I'll run a test to see if it's possible to request an encrypted stream by timecode, then buffer it for composition with another encrypted stream.
EME is a spec for a communication channel between script in a web page and a browser, with the idea that the browser then talks to a DRM module. It's not a spec for a communication channel between the browser and a DRM module.
This is important, because it means that you end up with DRM modules that are tied to a particular browser.
The NPAPI plugin situation is unfortunate in all sorts of ways, but the one good thing it had going for it was that there _was_ an API that multiple browsers all implemented, such that a single plugin binary woudl work in all of them (modulo the usual bugs and incompatibilities you have when there are multiple implementors of an API).
Unfortunately, 3 of the 4 main browser vendors also happen to be DRM vendors, and were rather united in their opposition to the W3C creating a specification for the communication channel between the browser and the DRM module.