- From: David Dorwin <ddorwin@google.com>
- Date: Thu, 28 Jun 2012 15:33:53 -0700
- To: "Sunyang (Eric)" <eric.sun@huawei.com>
- Cc: "public-html-media@w3.org" <public-html-media@w3.org>
- Message-ID: <CAHD2rsg8bv7n9ypZEsupz6g6A5QBugWo23RU7ZZQnhiGiJZ4=w@mail.gmail.com>
On Thu, Jun 28, 2012 at 1:19 AM, Sunyang (Eric) <eric.sun@huawei.com> wrote:
> Can I deduce that we the session can be reused by different media
> element at different time.****
>
> Thus the key gotten from license server can be reused when the same
> content arrives at user agent if the session remained after previous
> content is decrypted and played.****
>
> Right?
>
See the first item in "Advantages of this approach" and the bullet "Session
objects must be implicitly or explicitly associated with media element(s)."
This model fits more naturally with sharing since the session object is not
created by a specific media element. However, we have not decided whether
to support that use case, at least at this time. If we think we might want
to eventually support sharing, though, this design seems more appropriate.
If you are interested in such support and/or have use cases, please start a
thread on sharing session objects.
> ****
>
> ** **
> ------------------------------
>
> 孙扬
> 华为技术有限公司 Huawei Technologies Co., Ltd.
> **[image: Company_logo]**
>
> 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!****
>
> *发件人:* David Dorwin [mailto:ddorwin@google.com]
> *发送时间:* 2012年6月27日 9:30
> *收件人:* public-html-media@w3.org
> *主题:* [EME] Separating key session creation from the media element (using
> a MediaKeySession constructor)****
>
> ** **
>
> In today's teleconference [1], we decided to create a session object [2]
> with video.generateKeyRequest() rather than video.createKeySession() or
> something similar. While working on the change proposal, I realized that
> there are good reasons to consider separating object creation from the
> media element (something we had not discussed). I think the potential
> benefits are compelling enough to revisit this issue. Hopefully we can have
> a quick discussion in email and move forward with one of these solutions.
> If you are interested in the API design, please provide feedback and/or
> state your preference soon. In parallel, I'll continue working on the
> change proposal (ETA is now tomorrow).****
>
> ** **
>
> The new option is to create session objects using "new
> MediaKeySession(keySystem, mimeType)". For example:****
>
> function handleNeedKey(event) {****
>
> var session = new MediaKeySession(keySystem, mimeType);****
>
> if (session) {****
>
> session.onkeymessage = handleKeyMessage;****
>
> session.onkeyerror = handleKeyError;****
>
> session.generateKeyRequest(initData);****
>
> var video = event.target;****
>
> video.addKeySession(session);****
>
> }****
>
> }****
>
> ** **
>
> Another variant would be to add initData to the MediaKeySession
> constructor and specify that the constructor generates a key request. This
> would eliminate the need for generateKeyRequest() and have most of the
> benefits of the video.generateKeyRequest() solution discussed in the
> teleconference. For example:****
>
> function handleNeedKey(event) {****
>
> var session = new MediaKeySession(keySystem, mimeType, initData);****
>
> if (session) {****
>
> session.onkeymessage = handleKeyMessage;****
>
> session.onkeyerror = handleKeyError;****
>
> var video = event.target;****
>
> video.addKeySession(session);****
>
> }****
>
> }****
>
> ** **
>
> *Advantages of this approach*****
>
> 1. This might make more sense if we eventually decide to support
> sharing sessions between media elements (
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16615 and
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17202).****
>
>
> 1. Any of the "session = video.foo()" solutions result in an implicit
> relationship.****
>
>
> 1. It might enable initiating key exchange *before* the media element
> starts loading. [3]****
> 2. The resulting object could be used for Key Release (
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199) without needing
> to create a "dummy" media element (
> http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0107.html)
> or defining a separate object just for key release (
> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#key-release-manager
> ).****
> 3. MediaSource is using this model ("new MediaSource";
> http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0071.html),
> and it would be nice to have consistency.****
> 4. In the first variant only, explicit separation of creation from
> actions.****
>
> ** **
>
> *Effects of this approach*****
>
> The primary effect is that the session object is not *implicitly* associated
> with a media element.****
>
> ** **
>
> Because initData should contain all the information (i.e. the appropriate
> ISO CENC PSSH) necessary to obtain a license and verify that the specified
> key system is supported, the session object should not need to be
> associated with a specific element (or source file/stream) until its keys
> are needed to decrypt content.****
>
> ** **
>
> However, the separation does require the following:****
>
> - The MIME type must be explicitly specified to the session object.****
>
>
> - This is similar to the MediaSource constructor, which takes a type
> string.****
> - For the case where the object is created in response to a needkey
> event, we could even provide the current MIME type as an attribute of the
> event.****
> - Since the MIME type is specified separately, the media element
> would need to fail addKeySession() or only use a session if the
> types were compatible.****
> - (This would be required anyway if we wanted to address advantage
> #2 above. [3])****
>
>
> - Session objects must be implicitly or explicitly associated with
> media element(s).****
>
>
> - This is similar to MediaSource, which provides a URL to video.src.**
> **
> - Implicit example: All media elements may use all sessions.****
> - Explicit example: video.addKeySession(session);****
>
> ** **
>
> Compared to the video.generateKeyRequest() solution:****
>
> - The second variant (constructor generates a key request) is very
> similar.****
> - The first variant (constructor does NOT generate a key request):****
>
>
> - Requires one or two more lines of application code during
> initialization.****
> - Requires an object(s) must be created first for each KeySystem in
> the use case where generateKeyRequest(keySystem, initData) can be called
> repeatedly until a supported combination is found.****
>
>
> - This seems accpetable. [4]****
>
>
> - No longer implicitly enforces that generateKeyRequest() is called
> before addKey().****
>
>
> - We could just choose not to enforce this but instead require that
> all key systems support generateKeyRequest() by returning a keymessage so
> that applications can always follow this pattern. That was the main goal of
> this requirement anyway.****
>
>
> - No longer implicitly enforces that a session object represents
> exactly one initData value.****
>
>
> - Instead, subsequent generateKeyRequest() calls should explicitly
> fail, at least if a previous call was successful.****
>
> ** **
>
> ** **
>
> [1] http://www.w3.org/2012/06/26-html-media-minutes.html****
>
> ** **
>
> [2] See
> http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0054.html
> and https://www.w3.org/Bugs/Public/show_bug.cgi?id=16613****
>
> ** **
>
> [3] Currently, the media element must have started loading before
> generateKeyRequest() can be called. WebKit, at least, does not create the
> underlying media engine until loading starts. Even if we could work around
> this, the media element would need to somehow know the MIME type it *will*be provided so that the user agent or the CDM can parse the initData. If
> we separate the CDM from the media element, implementations should be able
> to create the underlying objects immediately regardless of the media
> implementation.****
>
> ** **
>
> [4] If the combinations passed to generateKeyRequest() fail****
>
> - Synchronously:****
>
>
> - Creating an object to call this function doesn't seem too bad for
> the application. It should just be an extra line of code****
> - Note: Failing synchronously in any design may require the user
> agent to be able to parse at least part of the initData and determine
> whether it contains data for one of the key systems it supports.****
> - Assuming that creation of the session object causes the related
> CDM to spin up, CDMs may be spun up unnecessarily in the case that
> the generateKeyRequest() call fails. Fortunately, this would happen
> asynchronous to the application and should not affect performance.**
> **
>
>
> - Asynchronously:****
>
>
> - Creating an object is likely to be a very minor part of the logic
> required to support this.****
>
>
Attachments
- image/jpeg attachment: image001.jpg
Received on Thursday, 28 June 2012 22:34:43 UTC