[Bug 19156] New: Switching decoders when the key system is specified

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

           Summary: Switching decoders when the key system is specified
           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: ddorwin@google.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org


Both v0.1 and the current version of the OO API allow the key system to be
specified at any point after loading has started. They even require that the
key system not be chosen or associated, respectively, until after loading has
started. As a result, it is very likely that the key system will be set AFTER
some frames have been decoded. For key systems/CDMs that include a decoder (or
entire video pipeline), this means that the decoder may change when the key
system is selected. This is primarily (only?) a problem if there is some clear
content being decoded/played before the encrypted content so decoding could
start before a key system was specified.

Supporting decoder changes may be very difficult to implement, especially
without restrictions on the content. For example, the switch might occur in the
middle of a group of frames that depend on previous frames to decode subsequent
frames. While this could be worked around, it might be better to avoid this
situation completely.


Some options:
1) Require the key system to be specified before loading and/or decoding
starts. If it is not specified by this time, it cannot be set later, meaning
decryption would not be possible. This would likely reduce the utility of the
needkey event.
2) Allow switching decoders whenever Media Source Extensions allow changing
codecs/decoders.
3) Switch decoders when the first encrypted frame is encountered, possibly
requiring the next item.
4) Establish limitations on which frames can be encrypted. For example, P-and
B-frames may not be encrypted if the I-frame is not. Due to seeking, this would
apply throughout a stream and not just to the beginning.
5) Switch immediately and drop frames if necessary.
6) Suggest the above to applications and make it a quality of implementation
issue for applications.
7) Leave the behavior undefined, making it a quality of implementation issue
for user agents.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 1 October 2012 04:57:36 UTC