Re: Encrypted Media Extension bugs for discussion during 2012-06-12 teleconference

On Mon, Jun 11, 2012 at 8:04 PM, Vickers, Mark <
Mark_Vickers@cable.comcast.com> wrote:

>  There is also related work defining content protection requirements in
> the Web & TV IG Media Pipeline TF:
>
>  http://www.w3.org/2011/webtv/wiki/MPTF#Content_Protection
>
>  Thanks,
> mav
>
>
>
> On Jun 11, 2012, at 8:53 PM, "Paul Cotton" <Paul.Cotton@microsoft.com>
> wrote:
>
>    The original email that described this proposal is at:****
>
> http://lists.w3.org/Archives/Public/public-html/2012Feb/0273.html****
>
> There are several references in that email that will provide background
> for the requirements that the proposal tries to meet.****
>
> ** **
>
> And of course the proposal itself is at:****
>
>
> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
> ****
>
> ** **
>
> There was a presentation and demo of the software implementing the
> proposal at the May F2F.  I am not sure if that presentation was ever
> archived but perhaps it could be posted in response to your request.
>
>
With Chrome/Chromium version 20 (current version of beta channel) or later,
you can try the demo by running the following command line:
  chrome --enable-media-source --enable-encrypted-media
--enable-video-track --no-sandbox
http://downloads.webmproject.org/adaptive-encrypted-demo/adaptive/dash-player.html

Make sure you don't have any other Chrome instances running or the switches
won't work.

David

>  /paulc****
>
> ** **
>
> Paul Cotton, Microsoft Canada****
>
> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3****
>
> Tel: (425) 705-9596 Fax: (425) 936-7329****
>
> ** **
>
> *From:* Sunyang (Eric) [mailto:eric.sun@huawei.com]
> *Sent:* Monday, June 11, 2012 10:37 PM
> *To:* David Dorwin; public-html-media@w3.org
> *Subject:* 答复: Encrypted Media Extension bugs for discussion during
> 2012-06-12 teleconference****
>
> ** **
>
> Hi David and all****
>
>  ****
>
> Can anyone give me an introduction/background material (email, txt, word
> or ppt) about this encrypted media extension?****
>
> I plan to attend today’s conference call, and I am reading the bugs listed
> below.****
>
> Thanks a lot if any.****
>
>  ****
>
> Yang****
>
> Huawei****
>  ------------------------------
>
> 孙扬
> 华为技术有限公司 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!****
>
> *发件人**:* David Dorwin [mailto:ddorwin@google.com]
> *发送时间:* 2012年6月12日 9:07
> *收件人:* public-html-media@w3.org
> *主题:* Re: Encrypted Media Extension bugs for discussion during 2012-06-12
> teleconference****
>
>  ****
>
> I changed the table to plain text below so it is hopefully more readable
> in the archives.****
>
>  ****
>
> On Mon, Jun 11, 2012 at 5:40 PM, David Dorwin <ddorwin@google.com> wrote:*
> ***
>
>  In the first HTML WG media teleconference, we will discuss as many of
> the following Encrypted Media Extension bugs as we can get through. (See
> http://tinyurl.com/7tfambo for a full list.) I've provided some brief
> notes for each bug below the list. I'll also start threads for some of
> them.****
>
>   ****
>
> ID          Sev Pri  OS  Assignee                           Status
> Resolution    Summary****
>
> 16612^  nor  P1   All  adrianba@microsoft.com NEW     ---    Consider
> wrapping all encrypted media methods inside a new interface****
>
> 16613    nor  P1   All  adrianba@microsoft.com NEW     ---    Consider a
> more object-oriented design in which sessions are represented as objects**
> **
>
> 16548    nor  P2   All  adrianba@microsoft.com NEW     ---    Require
> generateKeyRequest() in all cases for all Key Systems****
>
> 16549^  nor  P2   All  adrianba@microsoft.com NEW     ---    Remove
> initData parameter from addKey()****
>
> 16552    nor  P2   All  adrianba@microsoft.com NEW     ---    Consider
> making needkey a simple event****
>
> 16738    nor  P2   All  adrianba@microsoft.com NEW     ---    Provide
> more guidance on heartbeat implementation****
>
> 17199    nor  P2   All  adrianba@microsoft.com NEW     ---    Provide
> examples for and get feedback on Key Release****
>
>  ****
>
>  ^ We will defer discussion of these since they depend on other bugs in
> this list.****
>
>  ****
>
>  ****
>
> * 16612: Read for background, but we will defer discussion until we decide
> on 16613.****
>
> * 16613: This is the most important since so many other bugs depend on or
> are affected by it. I've added some pros and cons as well as references to
> many other bugs that may be at least partially addressed by objects. There
> is a link to a formatted version of the bug in Comment 3<https://www.w3.org/Bugs/Public/show_bug.cgi?id=16613#c3>
> .****
>
> * 16548: Summary: Making the uncommon simplest case slightly more complex
> simplifies implementation and increases consistency.****
>
> * 16549: Read for background, but we will defer discussion until we decide
> on 16613 and 16548.****
>
> * 16552: Are there strong preferences for simple vs. complex events? Note
> that we could consider making all events simple if we address 16613.****
>
> * 16738: How should heartbeats be implemented? keymessage followed by a
> reply using addKey() or as separate key requests/sessions?****
>
> * 17199: It would be good to get more feedback in the area of key release,
> especially regarding whether KeyReleaseManager should be a singleton and/or
> a member of window.****
>
>   ****
>
>