[Bug 19788] New: 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

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 30 October 2012 22:27:28 UTC