Re: [EME] Switching decoders when the key system is specified

As discussed during the teleconference, there are some implicit assumptions
below.

The first is that once you select a key system (and thus decoder), you
cannot change it. In other words, you cannot use multiple key systems
during the life (between loads) of a media element.

Also, to be clear, unencrypted content is supported even after selecting a
key system. This means there is a requirement that CDM decoders can also
decode clear/unencryped content.

On Sun, Sep 30, 2012 at 10:00 PM, David Dorwin <ddorwin@google.com> wrote:

> I filed the following as
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19156. I'd like to start a
> discussion on the issue, possibly continuing during the teleconference
> Tuesday.
>
>
> 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.
>
>