Re: CfC: to publish Encrypted Media Extensions specification as a First Public Working Draft (FPWD)

Jet,

It is difficult to assess the likelihood of such fallback scenarios. They
are certainly possible, so it is in the hands of the service provider to
make that decision.

>From the perspective of commercial video service providers, the
Flash/Silverlight approach is significantly worse than the EME/CDM
approach. It is worse because the use of any specific CP system requires
every UA vendor to independently build a distinct solution and for every
use of that system to deploy UA specific API at the client application
layer. That would not be the case with EME/CDM. So, speaking for Cox,
EME/CDM is a huge improvement over the status quo.

I'm not sure how we can do better than EME/CDM at the current time. We
aren't going to define a universally acceptable, fully PAS defined CP
system any time soon (if ever), and I highly doubt anyone else is either.
However, if and when someone does so, then we could add it as a second
mandatory CDM in a newer version of EME, along side the existing, and
admittedly inadequate ClearKey CDM.

Or do you have some concrete ideas about how to do this better?

G.

On Fri, Feb 1, 2013 at 9:57 AM, Jet Villegas W3C <w3c@junglecode.net> wrote:

> The scenario you describe seems very unlikely given the realities of
> DRM-protected content distribution. The only likely service degradation is
> "no service" for UA's without the installed CDM's. The distribution of
> CDM's is very tightly tied to revenue share %, plug-in bundling deals,
> breach response contracts, and other binding agreements between user agent
> providers and DRM content distributors. UA's that don't sign such deals and
> their users are locked out of the content. I don't see this to be an
> improvement to the Flash and Silverlight alternatives in use today, and we
> really should do better than that.
>
> --Jet
>
>
> On Fri, Feb 1, 2013 at 7:56 AM, Glenn Adams <glenn@skynav.com> wrote:
>
>>
>> On Thu, Jan 31, 2013 at 8:48 PM, L. David Baron <dbaron@dbaron.org>wrote:
>>
>>> On Thursday 2013-01-31 16:39 -0700, Glenn Adams wrote:With CDMs, on the
>>> other hand, the data communicated between parties
>>> is the tuple (encrypted data, key system).  This means the
>>> underlying data are meaningless unless both parties know what the
>>> key system is.  This, in turn, is why it's important that the key
>>> systems or the content decryption modules implementing them be
>>> registered.
>>>
>>
>> From the content authoring perspective as well as actual function of EME,
>> the only reason to employ a registry is to prevent name collisions for key
>> string identifiers. Since EME defines use of reversed DNS identifiers, then
>> this implicitly satisfies that requirement.
>>
>> From the perspective of UA implementers, a registry containing additional
>> information -- e.g., a full or partial specification of the key system, a
>> contact point for obtaining additional information or licensing, etc. --
>> would only be needed if a UA wished to directly implement a CDM that
>> supported some key system. Alternatively, a UA implementer could provide an
>> Add-On/Extension mechanism to permit system administrator or end user
>> installation of a CDM implementation supplied by a third party.
>>
>> For example, let's say I sign up for a first release HD video service
>> that encrypts its media streams. That sign-up service may entail
>> determining if my UA supports certain media types and certain key systems.
>> If it does not support the required key system, then it may ask me to
>> authorize downloading an Add-On/Extension that does support it. If I don't
>> authorize it, or if the UA does not support downloading a CDM, then the
>> service provider may choose instead to use one of the built-in CDMs
>> supported by the UA as determined when querying support for media types and
>> key systems. If the service provider doesn't find an acceptable supported
>> CDM, then it may offer a lower level service, such as non-HD or non-first
>> release, etc.
>>
>> Do you believe this scenario is infeasible given the current design of
>> EME?
>>
>>
>>
>