Depending on the container, the indication that the stream may be encrypted may not include any type of key identifier that would allow the user agent to determine whether it has the key.

Assigned to David for follow-up.

The way I read step#5 of the createSession() method, a keymessage event will always be fired. This is going to be unnecessary overhead in cases where the key is already known, either because it was previously acquired and is still live or because it was embedded in the initData. Can we simply not fire that message if the key is already available?

(In reply to comment #3)
> The way I read step#5 of the createSession() method, a keymessage event will
> always be fired. This is going to be unnecessary overhead in cases where the
> key is already known, either because it was previously acquired and is still
> live or because it was embedded in the initData. Can we simply not fire that
> message if the key is already available?

This is related to the algorithm in 5.2, which results in a "needkey" event. The "keymessage" event you refer to is not directly related. Since createSession() is always called by the application, the application is causing the keymessage events, which it needs in order to request a license. The application can avoid calling createSession() in response to a needkey event regardless of the outcome of this bug.

(In reply to comment #4)
> (In reply to comment #3)
> > The way I read step#5 of the createSession() method, a keymessage event will
> > always be fired. This is going to be unnecessary overhead in cases where the
> > key is already known, either because it was previously acquired and is still
> > live or because it was embedded in the initData. Can we simply not fire that
> > message if the key is already available?
> 
> This is related to the algorithm in 5.2, which results in a "needkey" event.
> The "keymessage" event you refer to is not directly related. Since
> createSession() is always called by the application, the application is causing
> the keymessage events, which it needs in order to request a license. The
> application can avoid calling createSession() in response to a needkey event
> regardless of the outcome of this bug.

Let me restate to make sure I understand. You are saying that according to 5.2 if the CDM determines that the key needed is already present, it will not cause the needkey event to be fired. Since the needkey event is not received by the media element, the app never calls createSession()?

If that is the case, then all of the aspects which are managed via MediaKeySession become problematic I think. For example - key related errors, key lifetime, adding new keys. I think I am mis-interpreting the model somehow.

Do we assume that the CDM may have licenses which are not attached to a MediaKeySession ?

For example, might a CDM retain a license after the MediaKeySession in which it was delivered is destroyed ? Perhaps some CDMs will keep licenses across page unload/reload ?

If yes, then it must be possible to obtain a new MediaKeySession associated with one of these cached licenses. That need not involve interaction with the license server.

The needkey -> createSession sequence is the only way that a new MediaKeySession is created. At least in such a way that it could be associated with a pre-existing license, because that can only be done with correct initData.

So, I'd conclude that needkey should always be sent, whether or not a license already exists for the content.

[I would not expect a keymessage to result from creating the session, though, but apparently there's a different bug for that]

I agree with this 100%. And I raised the issue of whether keys/licenses are allowed to be retained in another bug. I think it is obviously a useful thing to have the capability to retain licenses across sessions, pages, and browser instantiations. 

(In reply to comment #6)
> Do we assume that the CDM may have licenses which are not attached to a
> MediaKeySession ?
> 
> For example, might a CDM retain a license after the MediaKeySession in which
> it was delivered is destroyed ? Perhaps some CDMs will keep licenses across
> page unload/reload ?
> 
> If yes, then it must be possible to obtain a new MediaKeySession associated
> with one of these cached licenses. That need not involve interaction with
> the license server.
> 
> The needkey -> createSession sequence is the only way that a new
> MediaKeySession is created. At least in such a way that it could be
> associated with a pre-existing license, because that can only be done with
> correct initData.
> 
> So, I'd conclude that needkey should always be sent, whether or not a
> license already exists for the content.
> 
> [I would not expect a keymessage to result from creating the session,
> though, but apparently there's a different bug for that]

It appears we are already doing what this bug originally suggested and have been doing it since the original draft. Step 5 of http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#algorithms-encrypted-stream uses the "cdm to determine whether the key is known" and skips firing the event if the key is known.

However, it's unclear whether this is possible with all containers and what to do if initData represents more than one key. As an example of the first issue, the ISO PSSH does not necessarily identify all keys that might be obtained using it.

So, it seems we need to decide whether to remove the existing text rather than adding text as suggested by the title.

I think removing the existing text makes sense (thus always firing needkey).

I am also in favor of removing the existing text and always firing a needkey, relying on the application to handle duplicate Initialization Data.
 
One of the most important reasons is that there is no guarantee that the user agent can determine whether all the keys associated with the Initialization Data have already been received. For example, there is no guarantee that the CENC PSSH lists all key IDs it represents.

One thing the user agent could do is avoid sending duplicate needkey events for the same Initialization Data. For example, if the PSSH is exactly the same for audio and video or for two video streams in adaptive streaming. A single bit difference, would nullify this, though, so it might be best to leave to the application/server.


I think the main question is 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? Also, is the common logic that each application might need to include worth complicating the user agents and possibly restricting use cases?

This was discussed at the March 12 telecon, but we did not reach a conclusion. There was a good discussion of the various issues, which can be referenced at http://www.w3.org/2013/03/12-html-media-minutes.html#item05

It seems that the core issue is avoiding the creation of duplicate sessions and unnecessary network transactions that may occur as a result of the needkey event. The specific issue of whether to fire a needkey event may be a detail of the larger solution. Bug 19208 is related to this.

We will address the general issue in bug 21855.

*** This bug has been marked as a duplicate of bug 21855 ***

(In reply to David Dorwin from comment #8)
> It appears we are already doing what this bug originally suggested and have
> been doing it since the original draft. Step 5 of
> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-
> media.html#algorithms-encrypted-stream uses the "cdm to determine whether
> the key is known" and skips firing the event if the key is known.
> 
...
> So, it seems we need to decide whether to remove the existing text rather
> than adding text as suggested by the title.

I removed this text in https://dvcs.w3.org/hg/html-media/rev/84be32b27d5d as discussed in this bug and consistent with the decision in bug 21855.