Re: [EME] specification question: key Sytem selection

On Wed, Jul 4, 2012 at 7:13 AM, Mark Watson <watsonm@netflix.com> wrote:

>
>  On Jul 2, 2012, at 2:42 AM, Zhouhaojun wrote:
>
>   Hi Mark,****
>  ** **
>  I think Eric’s question is that it’s not clear how UA get to know the
> key systems supported by the file.
>
>
>  The UA, together with the CDMs it supports, need to get that information
> from the file. File format specifications need to define how they signal
> the encryption system used and content protection mechanisms supported by
> the file.
>
>  For example the mp4 file format has various fields which describe the
> Protection Scheme (in mp4 language) that the file supports. If this
> Protection Scheme is "Common Encryption" (cenc) then the Protection System
> Specific Information (push) boxes tell you which actual Protection Systems
> ( = keysystems) are supported.
>
>
So, It is clear now, the UA will get the key system from the initData of
meta data of media file.


>   ****
>  ** **
>  Here is my understanding: UA can get the information of key systems from
> the HTMLSourceElement.keySystem (which is mentioned explicitly in the
> draft)  or from the metadata in the file (which is not mentioned in the
> draft explicitly, maybe we need some words to explain it).****
>  ** **
>  How UA get initData is not clear too.
>
>
>  It has to get it from the file. We assume that if the UA supports use of
> encrypted media with file format X then it will know enough about that file
> format to get the initData out.
>

This means the media file including the initData should be downloaded to
the UA, but in other email thread, I know the initData may not be a part
the media file, so it will still be mp4 like format or a more common
format? (From you and David's reply, for each format of file, the
initData's structure is different).




>
>   See example 7.2.2 “other content decryption module”, the app get
> initData from key needed event before calling generateKeyRequest. So it
> seems that UA can get the initData from the file and set the
> MediaKeyNeededEvent.initData. Some clarifying words may be needed also.***
> *
>  ** **
>  Btw, can MediaKeyNeededEvent.keySystem contain multiple supported key
> systems, so app can select preferred one from them?
>
>
>  No, we just leave the keysystem as null here and the app needs to try
> the ones it supports as I described.
>

Why leave as null for the needKey.keyssystem, even if the UA know the key
system from the initData, why we leave it as null? for the app try the ones
part, I can understand it.


>
>  Since the functional split between UA and CDM is not fully defined in
> the specification, it could be that determining if a file supports a
> keysystem requires some work by the CDM. So we don't want to require the UA
> to do that for every keysystem. With the current design it is done only for
> the keysystems that the app supports and in app preference order.
>
>  …Mark
>
>   ****
>  ** **
>  ** **
>  Best Regards,****
>  ** **
>  Haojun Zhou****
>  Email: zhouhaojun@huawei.com****
>  Huawei Nanjing R&D Center, 101 Software Avenue, Yuhuatai District,
> Nanjing, Jiangsu, PRC.****
>  ** **
>  ** **
>  ** **
>   *发件人:* 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!****
>   ** **
>
>
>


-- 
Yang
Huawei