- From: <bugzilla@jessica.w3.org>
- Date: Wed, 31 Oct 2012 08:46:14 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19788 --- Comment #4 from Mark Watson <watsonm@netflix.com> --- There are two subcases: a) The player encounters some new information in the stream that indicates that a previously unseen KeyId is needed b) The player encounters some media encrypted using a key it does not have, but for which it already has initData For (b), I think the CDM should just send a keymessage. For (a), we need to understand how we want to handle this 'new information', which we could call new initData. I see two options: (a)(i) assume the CDM just handles it internally, putting it into case (b) (a)(ii) require it to be sent up to application, like the original initData This 'subsequent initData' differs from the initial initData because the keysystem has already been selected and it's possibly more embedded in the stream (rather than being in some kind of initialization segment). So (a)(i) should be possible and makes things rather simple. On the other hand, for initial initData we have the possibility for the application to process or even construct this. Do we want that possibility for subsequent initData as well ? If yes, then the next question is whether this should be dealt with inside the existing MediaKeySession or whether another one should be constructed, or whether this should be up to the CDM. (a)(ii)(1) [same session] We need to fire a needkey-like event on the same session and have a new method on the session to add initData (a)(ii)(2) [different session] We fire a needkey event and the app creates a new session (a)(ii)(3) [CDM decides] Both of the above are supported I think I have largely just enumerated the options in the comments above. My preference for (a) is to support (a)(i) and (a)(ii)(2). -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 31 October 2012 08:46:19 UTC