16553 2012-03-28 00:58:03 +0000 Consider not firing a needkey event when a potentially encrypted stream is encountered if the key is already known 2014-01-18 01:48:03 +0000 1 1 1 Unclassified HTML WG Encrypted Media Extensions unspecified All All RESOLVED DUPLICATE 21855 P3 normal --- 24323 1 ddorwin ddorwin eric.carlson mike philipj public-html-media public-html-wg-issue-tracking steele watsonm public-html-bugzilla oldest_to_newest 66172 0 ddorwin 2012-03-28 00:58:03 +0000 From step 8 of section 5.2. Potentially Encrypted Stream Encountered in v0.1: This could be skipped if the key has already been set, but always sending the event seems easier. We need to decided whether this adds to many complexities for applications and is worth requiring user agents to track whether to send the event. 72007 1 ddorwin 2012-08-10 02:28:37 +0000 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. 72926 2 adrianba 2012-08-28 20:56:39 +0000 Assigned to David for follow-up. 73185 3 steele 2012-09-04 16:31:35 +0000 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? 73226 4 ddorwin 2012-09-05 13:51:31 +0000 (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. 73236 5 steele 2012-09-05 15:59:18 +0000 (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. 77486 6 watsonm 2012-10-31 08:01:09 +0000 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] 77513 7 steele 2012-10-31 15:38:08 +0000 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] 77630 8 ddorwin 2012-11-01 00:51:49 +0000 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. 77690 9 steele 2012-11-01 17:47:44 +0000 I think removing the existing text makes sense (thus always firing needkey). 84195 10 ddorwin 2013-03-10 05:28:23 +0000 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? 86701 11 ddorwin 2013-04-24 18:00:06 +0000 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. 86895 12 ddorwin 2013-04-26 21:37:42 +0000 We will address the general issue in bug 21855. *** This bug has been marked as a duplicate of bug 21855 *** 95783 13 ddorwin 2013-11-05 01:44:40 +0000 (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.