[Bug 25218] Allow license management directly via MediaKeySession

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

--- Comment #22 from Joe Steele <steele@adobe.com> ---
(In reply to David Dorwin from comment #20)
> (In reply to Mark Watson from comment #19)
> > > > 
> > > > As an example, I don't think it makes sense for the result of the one-time
> > > > bootstrapping in comment #14 to be considered part of the session.
> > > > Presumably, the application never needs to manage such a key. However,
> > > > something like a domain license, which the application can join and leave,
> > > > should probably be exposed as its own session.
> > > 
> > > The application may want to manage it in the scenario I described above. If
> > > the application wants to hide the cost of acquiring such keys while the user
> > > is doing media selection for example, it would start up a session using some
> > > generic initData and close it once those keys are acquired. However that
> > > session does not contain any content keys and would therefore be not in
> > > compliance with the spec's definition of a "session". That session should
> > > also never be released or at least the application should not expect that
> > > releasing it will have any impact.
> > 
> > Ah. I had imagined that such a bootstrap step would take place the first
> > time you tried to play back content. The session would be created using the
> > initData and the bootstrap would take place together with or before the
> > license exchange.

It certainly could take place in that way. The issue with that is that the user
experience might not be optimal. We direct our developers to pre-load key
acquisition cost as much as possible to improve the user experience. 

In the simplest scenario, the user selects a video for first time playback and
hits "play". Since the player has never been used, an initial bootstrap happens
(taking multiple seconds). Now the license request happens (taking multiple
seconds). The user could end up wondering when their video is going to start
playing and hitting refresh on the browser. Painful. :-)

> > 
> > My assumption here is that such bootstrapping is needed only once when the
> > CDM is first used and perhaps once each time any persistent store is cleared.

This is correct, but I would add "when the CDM is first used for an origin".

> > 
> > If you have a bootstrap step which is needed for every browsing session,
> > this is a different matter.
> 
> I agree with what Mark said above.

The bootstrapping use case I am describing is a once-per-origin thing. However
chained licenses could require a lot more of this. For example requesting a new
root every 24 hours. 

> 
> > Still, it is not clear to me that because a keymessage response does not
> > contain any content keys this is not compliant to the specification. There
> > are any number of error cases where the keymessage response does not contain
> > any content keys. In your example, the keymessage contains all the content
> > keys identified in the initData (i.e. none).
> > 
> > Also, it's not clear that releasing this 'bootstrap' session would release
> > the bootstrapped state. In fact I would assume it would not. Same as if the
> > bootstrap was done at the beginning of a 'real' session, that state that it
> > establishes is still available to future sessions.
> 
> Agreed - the bootstrapped key would *not* be considered part of the session
> and you would have a compliant real session containing the content key(s).
> 
> This also happens in the background without the application needing to know
> the details of a specific implementation of a specific key system.

Agreed. Ideally the application can force it to happen early, but does not need
to know whether it happened or not. If it did not happen, or did not work, then
the key request will fail.

> 
> 
> If an application wanted to implement a key-system specific optimization for
> the very first playback on a subset of platforms, it seems what you really
> need is one of the following:
> 1) MediaKeys.bootstrap() to do the one-time non-session-related work.

What would this bootstrap call do? Does it generate a keyrequest and expect an
update()? If so -- how is it different than the current model? How is the web
app able to intermediate the bootstrap network requests?

> 
> 2) To know whether this process has already occurred.
> If not, you could initiate a dummy license request to cause the
> bootstrapping to occur. The resulting session would be a compliant session
> but with a useless license based on the initData provided.

The application doesn't need to know whether it has occurred, but if it has
occurred then the call should be zero-cost. 

This discussion seems to be heading towards a proposal to solve the simple
bootstrapping problem and not the larger issue. This is getting away from my
initial proposal to replace loadSession() and release(). I proposed this
because I think the conceptual model that says session==contentkeys is wrong. I
think that the application should treat the session as an opaque communication
channel without assuming it knows the relationship between the content playing
and the contents of the session. If the application needs to manage keys
directly, it can use the key ID for referring to them. That seems to be a
minimal amount of complexity to add, that enables a lot of flexibility later.

I am concerned we will paint ourselves into a corner if we don't change our
idea of what the session is. Multiple use cases (embedded keys, chained
licenses, multiple license sessions, Ultraviolet playback) will require
communication with a server prior to or during playback. If the application can
make assumptions about what is in the session, this is going to put up a
barrier against implementing these use cases in the future because the existing
loadSession/release behavior may not make sense in the context of those
features.

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

Received on Wednesday, 30 April 2014 23:55:07 UTC