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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19788

--- Comment #5 from David Dorwin <ddorwin@google.com> ---
(In reply to comment #4)
> 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

I think (b) is difficult to determine. For example, nothing guarantees that all
key IDs are specified in the PSSH. I also think it is an (admittedly minor)
implementation burden to have to check whether you have seen a PSSH (or
equivalent structure) for a key ID. Theoretically, CDMs may not keep the PSSH
around or even know how to parse all of it.

> For (b), I think the CDM should just send a keymessage.

What type of keymessage? Would it be key system-specific.

> For (a), we need to understand how we want to handle this 'new information',
> which we could call new initData. I see two options:

Is the 'new information' format a key ID or the same Initialization Data
(initData) format used elsewhere? I think Initialization Data should always be
the same format for a given container. Thus, if it's a key ID, we should call
it something else.

> (a)(i) assume the CDM just handles it internally, putting it into case (b)

What does it mean to be put 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 this data is defined as a key ID, then an application can construct it,
though I'm not sure what the use case is since createSession() takes a
different type of data. I think it's more likely that it would be sent to the
server to get a new key for the ID.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 31 October 2012 13:57:26 UTC