Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

On Mon, Feb 27, 2012 at 4:39 PM, Kornel Lesiński <kornel@geekhood.net>wrote:

> On Mon, 27 Feb 2012 23:27:42 -0000, Mark Watson <watsonm@netflix.com>
> wrote:
>
>  We'd like to get people's feedback on the proposal. It is posted here:
>>>> http://dvcs.w3.org/hg/html-**media/raw-file/tip/encrypted-**
>>>> media/encrypted-media.html<http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html>
>>>>
>>>
>>>
>>> In section 5.1. of the proposal there are steps:
>>>
>>> 2. Detect whether the frame is encrypted.
>>>         If the frame is encrypted
>>>         Run the steps above. ([...] Use handler to Decrypt the block
>>> [...])
>>>
>>> 3. Decode the frame.
>>>
>>> 4. Provide the frame for rendering.
>>>
>>>
>>> Do I understand correctly that once user is authorized CDM gives browser
>>> access to the decrypted bitstream of the media being played?
>>>
>>
>> It's not as clear as it could be, but the intention is that all three of
>> the following are possible, depending on the CDM:
>>
>> (1) The CDM returns the decrypted frame to the browser
>> (2) The CDM handles decryption and decoding and returns the decoded (raw
>> pixels) frame to the browser
>> (3) The CDM handles decryption, decoding and rendering and (possibly)
>> returns some kind of reference to the decoded frame to the browser
>>
>> (3) for example might be what happens on a TV that includes a secure
>> media pipeline as part of the platform. In that case the CDM doesn't itself
>> implement the decrypt/decode/render operations but makes use of platform
>> capabilities to achieve these.
>>
>
> Could this be made explicit in the specification (e.g. by adding necessary
> steps to the playback algorithm)? Currently the section 5.1 is normative
> and in my understanding does not enable CDMs to support cases (2) and (3)
> you've listed.


The slate grey color of the above steps indicates the text is
non-normative. It appears the text stating this was inadvertently removed
in one of the latest edits. Sorry for the confusion.

These steps are intended to illustrate the overall flow when block==frame,
which may be easier to understand, and is not a separate algorithm.

Step 9 of the main algorithm may similarly not support cases 2 and 3. It
merely says decrypt then continue, which does not really include all that
is necessary for those scenarios. We should ensure the normative algorithm
does not exclude these scenarios, but hopefully we can do so in a way that
avoids specifying too many implementation details or preventing some fourth
option.

>
>
> --
> regards, Kornel Lesiński
>