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

[Bug 16616] New: Support change of key during playback

From: <bugzilla@jessica.w3.org>
Date: Tue, 03 Apr 2012 16:21:41 +0000
To: public-html@w3.org
Message-ID: <bug-16616-2495@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16616

           Summary: Support change of key during playback
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Encrypted Media Extensions
        AssignedTo: adrianba@microsoft.com
        ReportedBy: watsonm@netflix.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


It is possible that a stream may encounter a different key for a given stream
after a key request session as been completed. How this should be handled is
not explicitly described; it may be up to the Key System and/or application but
that might lead to confusion and inconsistencies.

One option is to fire a keymessage to be sent to the server, which would return
a new license to provide via addKey(). The same Session ID would be used
because generateKeyRequest() is not called again. Note that this means a
keymessage even can occur after a keyadded event for the same session.

Another option is to fire a needkey event and follow the same steps as for the
first key. In this case, the application should call generateKeyRequest() to
generate the message. This would result in the generation of a new Session ID,
which is consistent with the first key.

If we select the first option, MediaKeyNeededEvent, the type of the needkey
event can be simplified because it would never be called with a known keySystem
or sessionId. If we select the second option, keySystem should almost certainly
be retained on MediaKeyNeededEvent and sessionId probably should be retained.

This decision should account for other use cases, such as heartbeat. For
heartbeat and any other CDM-originated message that isn't requesting a new key,
it probably makes sense to use the same Session ID and provide the request
directly via a keymessage event. This is essentially the first option above.
Selecting the second option for multiple keys does not necessarily mean that
heartbeat cannot work differently.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Wednesday, 4 April 2012 04:12:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:31 UTC