This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
If a session is created activating a Key System CDM and the key storage for that Key System already contains the key associated with the Key ID, then there is no need for the keymessage event. If this is correct, this is inconsistent with the current draft of the specification. The proposal would be to add the following sentence to the last paragraph of the ISOBMFF Container Guidelines: Likewise, if createSession() activates a Key System CDM and the key storage for that Key System already contains the key associated with the Key ID, then there is no need for the CDM to generate a keymessage event.
Is the intent to have a valid MediaKeySession without any messages being passed? If so, how would the application know that the session is ready/valid? Does it make more sense to try to avoid firing events that most likely result in the creation of an unnecessary MediaKeySession? This won't avoid messages in all cases, but it would probably address the most common cases.
We should also consider the case where the key is already available via whatever means but is not represented by a (active) session. Is this allowed? If so, how will the application know that the session is ready? Should keyadded be fired with no keymessage? Is it possible that a service/application would want to differentiate between different PSSH's (or other Initialization Data) containing the same key ID? (Or no key ID?) Maybe this is not a good idea and thus not allowed.
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.
(In reply to comment #3) > 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 I don't think scenario (ii) should happen. If the MediaKeySession object has been destroyed, the keys related to that session should have been deleted. This is the equivalent of calling close(). Thus, only (i) should be possible. > For (i), perhaps we should just return the existing MediaKeySession ? We previously discussed returning an existing MediaKeySession object, but it raises a lot of questions and involves the particularly thorny issue of synchronous calls to the CDM. See http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0133.html
(In reply to comment #4) > (In reply to comment #3) > > 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 > > I don't think scenario (ii) should happen. If the MediaKeySession object has > been destroyed, the keys related to that session should have been deleted. > This is the equivalent of calling close(). Thus, only (i) should be possible. That's fine for me. I can imagine scenarios where you need (ii) - for example licenses for offline use. In those cases, closing the browser doesn't delete the key from the CDM. > > > For (i), perhaps we should just return the existing MediaKeySession ? > > We previously discussed returning an existing MediaKeySession object, but it > raises a lot of questions and involves the particularly thorny issue of > synchronous calls to the CDM. See > http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0133.html Ok, yes, I see. The thread doesn't quite conclude, though. One option is that we require that the application knows whether a new license exchange is required or not. If the application creates a new MediaKeySession with the same initData it's because it really wants a new license exchange for those same keys (for some reason). In that case we would close this bug with WONTFIX. Another option would be to allow multiple MediaKeySession objects to refer to the same underlying key information. In this case the keyadded would be fired on the newly created MediaKeySession - i.e. it autonomously transitions from NOT_READY to READY when the CDM has processed the initData and determined that it already has the keys. In this second case we need to deal with the possibility of multiple MediaKeySession JS objects referring to the same key. Do they refer to the same session ? We might want to allow the sessionId attribute to be null when the object is first created and only obtain a value when the first message is fired. This would allow the sessionId to be determined asynchronously by the CDM.
*** Bug 20964 has been marked as a duplicate of this bug. ***
Is the goal of this bug to avoid creating a duplicate session? If so, would it be better to address this in bug 16553? I don't think we can guarantee that the CDM knows whether it has all the keys associated with the Initialization Data provided to createSession(). The best we might be able to do is determine whether a license request (keymessage) for the exact same Initialization Data has been sent. We might be able to get closer to the original bug summary by checking existing sessions that have received a license to see if they were started with identical Initialization Data. Still, there might be legitimate use cases where an application really wants a new request. As with bug 16553, how much burden is it on an application to compare (and possibly track) Initialization Data to avoid calling createSession() multiple times for the same data?
(In reply to comment #7) > Is the goal of this bug to avoid creating a duplicate session? If so, would > it be better to address this in bug 16553? Yes, I think the goal is to avoid duplicate sessions, but I think we wanted to avoid having firing needkey interact with a CDM. The initData may contain information for more than one key system.
This was discussed in the March 12th telecon, but no decision was reached. Adrian has an action [2] to discuss this with John. [1] http://www.w3.org/2013/03/12-html-media-minutes.html#item05) [2] https://www.w3.org/html/wg/media/track/actions/10
We will address the general issue in bug 21855. *** This bug has been marked as a duplicate of bug 21855 ***