[Bug 24082] Several issues discussed in the TF point to the need for defined extensibility points in EME

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

--- Comment #5 from David Dorwin <ddorwin@google.com> ---
(In reply to Adrian Bateman [MSFT] from comment #2)
> A significant number of PlayReady customers (I think around 50%) use the
> feature to transmit data within the license request to their licensing
> service. Since we expect these customers to continue to share backend
> infrastructure between EME-enabled web applications and native applications
> on other platforms, we needed to provide this capability in EME to avoid
> costly changes on the server side. See
> http://msdn.microsoft.com/en-us/library/ie/dn255041
Couldn't this be solved with a simple thin layer that 
> 
> While we understand the concern that supporting this kind of application
> specific data might encourage developers to adopt practices that make it
> harder to deploy CDM-agnostic applications, we don't believe that this will
> happen. One of the key goals of EME is to allow as much sharing of
> application code using HTML media elements as possible and this will be
> enough to encourage use of technologies like Common Encryption with multiple
> content protection systems.

We do believe this is a significant risk. Content providers are already
targeting subset(s) of clients. Moving to EME will be a significant effort (or
outsourcing) for some, and it seems unlikely that some of them will come back
and make their solutions interoperable later, especially if they do not have
the expertise in-house.

If we want true interoperability, providers will need to make some adjustments.
We believe they will make them given the advantages of migrating to HTML5. If
we think content providers will end up in the same place, what is the point of
adding a permanent crutch for the short term?

Alternatively, what can PlayReady do to ease the transition for these
customers?


(In reply to Adrian Bateman [MSFT] from comment #3)
> We think the following extension points should be contemplated:
So far, I'm not sure the use cases presented are as much extension points as
they are support for non-interoperable legacy solutions. It could be argued
that EME is already extensible. According to Wikipedia, extensibility means
“New capabilities can be added to the software without major changes to the
underlying architecture.” I believe that the MediaKeys and MediaKeySession
architecture is extensible, as shown with the addition of loadSession() to add
new capabilities. If EME is missing such capabilities, or we find that it is
during implementation, we should file bugs and address them. However, I don't
think adding what are essentially void* parameters is the right way forward.

> 1) MediaKeys constructor should take an optional dictionary.
>    The use cases for this are recorded in bug 24025.
I'm less certain about the dictionary now. I'll update that bug with more
discussion.

> 2) createSession should include an additional data parameter as described in
> comment 1 and comment 2. Joe proposes a dictionary here too.
> 
> 3) update should also include an additional data parameter. We believe the
> use cases for createSession map onto update as well, for example to
> influence the next message event.
What use cases are those? The PlayReady additional data use case or something
else? Is there data that must be provided in every message? Could the CDM store
such data from MediaKeySession and/or MediaKeys creation?

> Since bug 24025 is a subset of this issue, we recommend closing 24025 and
> tracking the work here so that we solve for this issue in one go.
These seem to be tracking separate use cases at the moment, and I think it
would be confusing to combine the discussions into one long bug. Let's see
where each discussion goes before merging them.

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

Received on Monday, 3 March 2014 23:07:26 UTC