Bugzilla – Bug 16616
Support change of key during playback
Last modified: 2013-07-02 15:39:01 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.
Assigning to David to be considered together with other needkey bugs (for example bug 18515).
The events involved depend on issue 19788.
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 ( and telecon discussion). This rules out the first option in the original report.
I think the resolution of bug 19788 will make it clear what should happen.
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.