W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2012

[Bug 19788] What, if any, event should be fired when no key is available to decrypt the block?

From: <bugzilla@jessica.w3.org>
Date: Wed, 31 Oct 2012 08:46:14 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-19788-2486-aHjpOEZEPL@http.www.w3.org/Bugs/Public/>

--- 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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:34 UTC