needkey event issues

We have several issues to address related to needkey that we may want to
consider together.

   1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=16553
   2. https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515
   3. https://www.w3.org/Bugs/Public/show_bug.cgi?id=19788


I just filed the third one, which I've included below along with subsequent
updates that weren't in the automated email sent to the list.

On Tuesday, October 30, 2012, wrote:

> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19788
>
>           Priority: P3
>             Bug ID: 19788
>                 CC: mike@w3.org, public-html-media@w3.org
>           Assignee: adrianba@microsoft.com
>            Summary: What, if any, event should be fired when no key is
>                     available to decrypt the block?
>         QA Contact: public-html-bugzilla@w3.org
>           Severity: normal
>     Classification: Unclassified
>                 OS: All
>           Reporter: ddorwin@google.com
>           Hardware: All
>             Status: NEW
>            Version: unspecified
>          Component: Encrypted Media Extensions
>            Product: HTML WG
>
> In the current draft, the Encrypted Block Encountered algorithm [1] may
> fire a
> needkey event if the required key is not available. For ISO BMFF/CENC^ and
> WebM, the needed keys can always be identified based on headers, so no new
> information should be available during the decrypt/decode phase that wasn't
> available when the user agent determined that the stream may be encrypted
> (Potentially Encrypted Stream Encountered algorithm [2]) and sent a needkey
> event. Thus, multiple identical events may be sent in certain valid
> scenarios.
> This issue is tracking whether we should have a different behavior in the
> case
> that a required key is unavailable. (Note that this is not a MediaError
> because
> there are legitimate use cases where a key may have been requested as a
> result
> of the Potentially Encrypted Stream Encountered event but has not yet been
> received by the time the key is needed.)
>
>
> Options include:
> * Report a "needkey" event on the media element.
> * Report a different event on the media element.
> * Report an event on the MediaKeySession element if one has been associated
> with the media element.
> * Report no event and assume the event from the Potentially Encrypted
> Stream
> Encountered algorithm is sufficient.
>  - This works for ISO BMFF/CENC and WebM and other container formats with
> “headers” but would not work for a container where key IDs can appear in
> blocks
> but not identified based on “headers”. One option in those cases would be
> to
> consider this the “may contain” case, which should then be renamed to
> reference
> the first time a key reference is encountered. (More on this below.)
>
> If we do send events in this case, how many events should be sent for the
> same
> key ID? Since audio and video (or multiple streams of each) may be
> processed at
> different times or on different threads, it's possible that an event could
> be
> fired for each even if they use the same key ID. Should we allow, prevent,
> or
> discourage this? (There is a similar issue for the Potentially Encrypted
> Stream
> Encountered algorithm when multiple files/streams/tracks contain the same
> Initialization Data.)
>
>
---------------------------------------------------------------------------------------------
Possible Solution

One option might be to change how we think about the two scenarios. This
might make implementations more difficult but would resolve some of these
issues.
* The first algorithm would be “First Time a Key Reference is Encountered.”
Each container would need to specify what this means. For example, ISO
BMFF/CENC might define this as encountering a PSSH even if the PSSH does
not explicitly reference a key. For WebM, this might be when
ContentEncryption/ContentEncKeyID is parsed. For a container without such
headers, it might be the first time each key ID is encountered (i.e. in a
block).
* The second algorithm would continue to be "Encrypted Block Encountered"
with the change that the Key Presence step does not fire an event or an
error in the case where the needed key is not available. Note that this may
or may not occur at the same time as the first reference to a specific key
(the first algorithm).

The first algorithm would be the only one that sends an event, and the
second one would describe the behavior of playback (see bug 18515).
Applications would not be informed that a key is needed for decrypting a
current block. They shouldn’t really need to know for key-related reasons,
but are there other reasons? Would/should existing events (i.e. stalled?)
cover any such needs?

---------------------------------------------------------------------------------------------

Follow-up: Should the event for the Encrypted Block Encountered algorithm
[1] contain Initialization Data or the key ID?

If we choose to report an event, we need to decide what data to report in
the event.
Step 7 of [1] says to fire a needkey event where "initData = block
initData". "block initData" was set in step 4, which says, "If the block
(or its parent entity) has Initialization Data, let block initData be that
initialization data."

The problem is that Initialization Data may not be readily available when
decrypting. Instead, the key ID is generally what is known for a given
block.

Which of the following should we specify?
1) The needkey event contain the Initialization Data, which can be sent to
the server just like it can for the Potentially Encrypted Stream
Encountered algorithm [2]. This has implementation overhead.
2) The key ID of the current block. This is easier to implement but
inconsistent with the Potentially Encrypted Stream Encountered algorithm
[2] and may not be useful for obtaining a key. This option is probably
better if we have a separate even name and/or fire it at different objects.


[These footnotes apply to all three updates through this one.]

^ Is this true for CENC, even in use cases case that involve key rotation?

[1]
http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#algorithms-enrypted-block
[2]
http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#algorithms-encrypted-stream