This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16616 - Support change of key during playback
Summary: Support change of key during playback
Status: RESOLVED WORKSFORME
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: David Dorwin
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on: 16738 19788
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-03 16:21 UTC by Mark Watson
Modified: 2013-07-02 15:39 UTC (History)
8 users (show)

See Also:


Attachments

Description Mark Watson 2012-04-03 16:21:33 UTC
It is possible that a stream may encounter a different key for a given stream after a key request session as been completed. How this should be handled is not explicitly described; it may be up to the Key System and/or application but that might lead to confusion and inconsistencies.

One option is to fire a keymessage to be sent to the server, which would return a new license to provide via addKey(). The same Session ID would be used because generateKeyRequest() is not called again. Note that this means a keymessage even can occur after a keyadded event for the same session.

Another option is to fire a needkey event and follow the same steps as for the first key. In this case, the application should call generateKeyRequest() to generate the message. This would result in the generation of a new Session ID, which is consistent with the first key.

If we select the first option, MediaKeyNeededEvent, the type of the needkey event can be simplified because it would never be called with a known keySystem or sessionId. If we select the second option, keySystem should almost certainly be retained on MediaKeyNeededEvent and sessionId probably should be retained.

This decision should account for other use cases, such as heartbeat. For heartbeat and any other CDM-originated message that isn't requesting a new key, it probably makes sense to use the same Session ID and provide the request directly via a keymessage event. This is essentially the first option above. Selecting the second option for multiple keys does not necessarily mean that heartbeat cannot work differently.
Comment 1 Adrian Bateman [MSFT] 2012-08-28 21:07:41 UTC
Assigning to David to be considered together with other needkey bugs (for example bug 18515).
Comment 2 David Dorwin 2012-11-01 07:46:01 UTC
The events involved depend on issue 19788.
Comment 3 David Dorwin 2013-03-09 03:49:48 UTC
The text in the original report is from https://dvcs.w3.org/hg/html-media/raw-file/eme-v0.1/encrypted-media/encrypted-media.html#issue-multiple-keys.

Note that we decided as part of the object-oriented design discussion that each initData would be a separate session ([1][2][3] and telecon discussion). This rules out the first option in the original report.

[1] http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0056.html
[2] http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0127.html
[3] http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0136.html
Comment 4 David Dorwin 2013-04-23 20:44:38 UTC
I think the resolution of bug 19788 will make it clear what should happen.
Comment 5 David Dorwin 2013-07-02 15:39:01 UTC
When new initData is encountered, a needkey event will be fired. The application can then create a new session by calling CreateSession(). This is essentially what was described in the second option in the original report.