[Bug 19208] Keymessage event not needed when Key System already has Key

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

--- Comment #3 from Mark Watson <watsonm@netflix.com> ---
It seems like a key in the CDM should always be associated with a session -
specifically the one that created it.

How about the following:

When createSession is called, if the CDM discovers that there is already a
key+session that matches the initData, there are two possibilities:
(i) there already exists a MediaKeySession object for this session
(ii) there is no existing MediaKeySession object for this session

For (i), perhaps we should just return the existing MediaKeySession ?

For (ii), a new MediaKeySession object should be created for this session and
that object should be in the same state that it was last time a MediaKeySession
existed for that session.

We could consider having a readystate attribute on the MediaKeySession. The
states I can think of are NOT_READY, READY, ERROR and CLOSED:
NOT_READY: the session does not yet have the key material called for by the
initData
READY: the session has the key material called for by the initData
ERROR: an error occured
CLOSED: close() was called or the session was otherwise closed and the key(s)
destroyed

[We would need to add a final state for secure proof of key release, say
COMPLETE]

I think the MediaKeySession definitely has these states. Whether we need to
expose them I am not sure: you generally don't wait for the MediaKeySession to
be READY before streaming data, as the key might not be needed right away.

The script can tell is the state is NOT_READY or ERROR by the receipt of a
keymessage or keyerror. The transition from NOT_READY to READY is marked by the
keyadded event. But you cannot know if the state is READY on creation, except
by the absence of the keymessage. This doesn't seem very robust.

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

Received on Thursday, 3 January 2013 00:19:29 UTC