Re: 答复: [EME] specification question: key Sytem selection

On Wed, Jul 4, 2012 at 12:18 AM, Sunyang (Eric) <eric.sun@huawei.com> wrote:

>   ------------------------------
>
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!****
>
> *发件人:* Mark Watson [mailto:watsonm@netflix.com]
> *发送时间:* 2012年7月4日 14:13
> *收件人:* Sunyang (Eric)
> *抄送:* public-html-media@w3.org
> *主题:* Re: [EME] specification question: key Sytem selection****
>
>  ** **
>
> ** **
>
> On Jul 3, 2012, at 10:12 PM, Sunyang (Eric) wrote:****
>
>
>
> ****
>
> Thanks for your reply.****
>
>  ****
>
> I guess you misunderstand my question.****
>
> My question is when encrypted block is detected by media element during
> resource fetch algorithm ,****
>
> how to choose the key system.
>

The application always chooses the key system to use; the media element
does not choose the key system. The only case where the UA "sets" the
current key system is when a <source> element is used to select the source
and the selected element specifies a "keySystem" attribute. Even in this
case, though, the key system to use for a particular source was specified
by the application and the UA is just processing the options.

If an encrypted block is detected, and multiple keysystems are supported by
> the file, and a keysystem has not been selected by the application, then
> the needkey event is fired. The needkey event in this case cannot specify a
> keysystem because multiple are still possible. If only one keysystem is
> possible at this point (because the file only supports one, for example),
> then this could be signaled in needkey.****
>
> ** **
>
> Now we only consider only one keySystem is supported by the file for
> simplification, if no selected key system, the web app will monitor the
> needKey event to retrieve the keySystem (How does needKey get the
> KeySystem?), if no return keysystem from needkey event, the web app need
> select one, so how? In section 7.3, the web app function (selectKeySystem)
> will test UA use canPlayType(“container format”,”keySystem options”) to
> test whether the UA support any keySystem for some kind of container format.
> ****
>
> ** **
>
> There is 2 question****
>
> **1)      **How needKey get the keySystem for the initData
>
It gets it from the keySystem attribute of the selected <source> or
the keySystem parameter to generateKeyRequest() if it was called before the
needKey event. Otherwise, keySystem is null.

Regarding your earlier questions about steps 6 and 9 of section 5.1, "key
system" is a variable that is set to null in step 1. Thus, it will be null
in the case you described.

> ****
>
> **2)      **If using canPlayType, we can only test whether UA can support
> any KeySystem for a certain container format, but how can we know that the
> result keySystem will support our media file? Do we mean for one container
> format, we can use one kind of KeySystem to cover?
>
This question (and much of this discussion) only applies to containers that
contain key system-specific information. ISO/MP4 is one such container.
This is not an issue for containers that use generic
information/identifiers. Also, UAs wouldn't be able to report a list of key
systems for a file in that for such containers.

One proposal (described by Adrian in the last call) is to call
generateKeyRequest() with key system-initData pairs until it succeeds. An
application might also be able to parse the initData to figure out which
key systems are supported.

> ****
>
> ** **
>
> I haven't had a chance to review the specification text - perhaps it does
> not say clearly what I have said above.****
>
> ** **
>
> Yes, the specification is not clear how the keySystem is generate between
> “need keySystem ” and “needKey generate KeySystem”.
>

I don't understand the quoted terms. Does my answer to question #1 above
address this?

> ****
>
> ** **
>
> Usually, it is the call to generateKeyRequest that selects the keysystem.*
> ***
>
> ** **
>
> In section 7.3 ,yes the caller has the keySystem information before call
> generatekeyRequest****
>
> ** **
>
> The application does need to specify a keysystem in that call, otherwise
> it is an error as you point out. ****
>
> ** **
>
> Yes, you are right****
>
> ** **
>
> The media element may not be able to decrypt the content until addKey is
> called with the key/license information. But I am not sure what the problem
> is that you see with this ?****
>
> ** **
>
> There is 2 question****
>
> **3)      **How needKey get the keySystem for the initData****
>
> **4)      **If using canPlayType, we can only test whether UA can support
> any KeySystem for a certain container format, but how can we know that the
> result keySystem will support our media file? Do we mean for one container
> format, we can use one kind of KeySystem to cover?****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> …Mark****
>
>
>
> ****
>
>  ****
>
> From specification,****
>
>  ****
>
> In step 6 of section 5.1 encrypted block encounted****
>
> It is said if the media element has a selected key system, then use it,***
> *
>
> If not, jump to key presence, there is no key system selection text  in
> step 9 Key Presence.****
>
> Step 9 only mentioned 3 choices: 1 key is available, 2 fire needKey event
> with “keySystem”,3 abort resource fetch procedure
>

Reiterating what I said above, "key system" is a variable that is set to
null in step 1. Thus, it will be null in the case you described.

>
>
****
>
>  ****
>
> What’s more, I think before the generateKeyRequest(KeySystem, initData) is
> called, the KeySystem is already****
>
> Selected, and the specification mentioned if KeySystem is null, it will
> throw a SYNTAX_ERROR.****
>
>
> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-generatekeyrequest
> ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>   ------------------------------
>
> 孙扬
> 华为技术有限公司 Huawei Technologies Co., Ltd.
> <image001.jpg>
>
> Phone: +86 25 56622934
> Fax: +86 25 56624081
> Mobile: +86 13851889004
> Email: eric.sun@huawei.com
> 地址：南京市雨花区软件大道101号 华为南京基地 邮编：210012
> Huawei Technologies Co., Ltd.
> No 101,Software Avenue, Yuhua District,Nanjing 518129, P.R.China
> http://www.huawei.com****
>  ------------------------------
>
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!****
>
> *发件人:* Mark Watson [mailto:watsonm@netflix.com]
> *发送时间:* 2012年7月1日 11:43
> *收件人:* Sunyang (Eric)
> *抄送:* public-html-media@w3.org
> *主题:* Re: [EME] specification question: key Sytem selection****
>
>  ****
>
> The key system is selected with the call to generateKeyRequest(). If that
> keysystem is not supported (by the browser, or by the file) then the call
> will fail and the app can try a different keysystem.****
>
>  ****
>
> Note that all three of the app, the file and the browser may support
> multiple keysystems. Only a keysystem in the intersection of these three
> sets may be used. There may still be more than one. The app needs to choose
> its favorite from that set, as there may be commercial implications of the
> choice for the app. The way we chose to implement that was by allowing the
> app to attempt generateKeyRequest with different key systems, in preference
> order, until one succeeded. That seems actable given that the set of
> keysystems in the intersection I describe above is likely to be very small
> (coming up with an example where there are 3, say, is already a challenge).
> ****
>
>  ****
>
> …Mark****
>
>  ****
>
> On Jun 29, 2012, at 8:30 PM, Sunyang (Eric) wrote:****
>
>
>
>
> ****
>
> After reading the specification, I have a question on Key System selection.
> ****
>
>  ****
>
> If media element’s source attribute has a keySystem attribute then we use
> this as selected keySystem, this is OK.****
>
> If no selected KeySystem, the specification says “jump to Key Presence”***
> *
>
>  ****
>
> The question is :****
>
>  ****
>
> At “jump to Key Presence” is a else if of “selected key system”, so here
> we have no idea about key system,****
>
> We may need let app or CDM to analyze the initData to find the KeySystem,
> but I have not seen any text for****
>
> Analyzing initData here, or I miss something?****
>
>  ****
>
> So where we select the Key System if no selected key system in media
> element?****
>
>  ****
>
>  ****
>  ------------------------------
>
> 孙扬
> 华为技术有限公司 Huawei Technologies Co., Ltd.
> <image001.jpg>
>
> Phone: +86 25 56622934
> Fax: +86 25 56624081
> Mobile: +86 13851889004
> Email: eric.sun@huawei.com
> 地址：南京市雨花区软件大道101号 华为南京基地 邮编：210012
> Huawei Technologies Co., Ltd.
> No 101,Software Avenue, Yuhua District,Nanjing 518129, P.R.China
> http://www.huawei.com****
>  ------------------------------
>
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!****
>
>  ****
>
> ** **
>