[Bug 20944] EME should do more to encourage/ensure CDM-level interop

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944

--- Comment #44 from David Dorwin <ddorwin@google.com> ---
tl;dr: Skip to comment #45.

comment #0 starts with the following threat example:
"a UA vendor... promulgating a CDM that no other user-agent can support, and
encouraging the creation of content for that CDM consumable only by that
user-agent."

A variant of that would be "encouraging the creation of content and
applications that are consumable only by a specific CDM and the user agent(s)
that support it."

While other interop issues have been discussed in this bug, I believe this one
is the most important for the web platform. If not addressed, siloed content
may simply be moved from native apps and plugins to <video> while remaining
accessible to only a fraction of user agents and users.


Much of the discussion that followed the threat example was about a key
system/CDM registry, but, as the original description notes, "These
requirements are not the only possible fix..." As I explain below, I do not
think such a registry is necessary or addresses the real issues.

The proposed uses (in comment #4 and elsewhere) for the information such a
registry might contain seem to fall into three primary categories:
1) Understanding the [observable] behavior, etc. to help identify the source of
problems, UA integration difficulties, interoperability problems, etc.
  1.1) This could also theoretically be used to implement compatible
functionality in other key systems.
2) Improve consistency of various implementations of a given key system across
UAs. For example, two browsers using the same OS APIs should behave
identically.
3) Ability to reimplement a CDM, i.e. if it becomes orphaned.

While important, I do not believe these address the primary interoperability
concern as they do not ensure that EME applications or content are
interoperable across key systems. For example, even if one knows how a CDM
operates, other key systems may not be able to replicate it or the content may
not contain the necessary information for other key systems (i.e. it relies on
information in a proprietary PSSH box).

A more direct and perhaps effective solution to #1 would be to document the
expected observable behavior of CDMs in the EME spec. That is, how and when
keys and licenses are obtained, destroyed, etc. (As with #1, this does not
cover robustness mechanisms, etc.)

#2 is really interoperability within a given key system. This is important and
really applies to all implementations of a key system, not just those using a
specific (e.g. OS) API. CDM providers should document how to use their APIs and
other underlying implementations in the appropriate locations. For example, if
there is an OS API, such documentation should be publicly available; if use of
the CDM requires other arrangements, such documentation should be provided as
part of those arrangements. It is good to remind CDM providers of this
recommendation (and to provide compatibility tests to verify implementations),
but I am not sure that a public registry is necessary to accomplish the goals.
Providing this information is in the CDM providers' interest as noted in
comment #39.

I believe #3 becomes less of an issue if we are successful in encouraging
interoperable applications, content, license acquisition, etc. (proposed
solution to #1). If a content provider supports multiple key systems, the
demise of one CDM does not itself make the content inaccessible. Content
availability mostly relies on the content provider except in the case of
permanent offline licenses. (Solutions for that depend on how the license was
issued and may have nothing to do with the CDM implementation.)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 27 May 2014 22:22:00 UTC