Re: Encrypted Media proposal: Summary of the discussion so far

On Sun, 04 Mar 2012 02:54:11 +0100, Christian Kaiser <kaiserc@google.com>  
wrote:

> The proposal does *not* prescribe which, if any, of these CDMs a browser
> vendor can or shall implement. A browser vendor can choose to implement  
> no
> CDM, and thus not support Encrypted Media playback.

This is not very reassuring. Except for browser vendors which have their  
own CDMs, implementing a CDM is not something one can "choose" to do, it's  
something one will be effectively forced to do in order to retain users  
and to do so one must ask permission from the CDM vendor, which can  
decline for any number of reasons.

> It does, however, specify a CDM that presumably any browser vendor can
> implement (Clear Key). Therefore, a baseline is established that makes  
> the
> proposal useful whether or not any other CDMs will be supported by anyone
> in practice.

Clear Key looks a lot like a placeholder, and one that no one who cares  
about preventing access to their content could possibly be happy with. If  
implementing only Clear Key were actually a viable alternative, then  
surely it should be the only CDM?

> A browser vendor can choose to implement additional CDMs, or, if desired,
> even a plugin mechanism for CDMs. Browser vendors can, but do not have to
> agree on a common plugin mechanism for CDMs if they find that useful.  
> Such
> a plugin mechanism's scope will be much smaller than e.g. NPAPI.

The CDM integrates tightly with and takes over part of the  
responsibilities of the media stack, so an API for would have to include  
at least:

1. Key exchange (the simple part).

2. A generic filter graph model, to integrate with the many various media  
frameworks in use.

3. The format of raw audio/video frames and their timestamps.

4. Overlays for CDM that don't return decoded frames, including the  
non-trivial problem of keeping a scrolling/animated overlay in perfect  
sync even if it is controlled by another process.

5. Audio/video sync between an arbitrary number of <video> elements,  
mixing those controlled by CDM and browser-native ones.

6. A way to signal failures in the CDM, e.g. "the key was revoked" or  
"your IP/country/User-Agent/etc is blacklisted".

This does not really seem smaller in scope than NPAPI. If this is not  
correct, it would help immensely if the details of the CDMs intended for  
production use were publicly disclosed.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Monday, 5 March 2012 13:54:13 UTC