- From: John Simmons <johnsim@microsoft.com>
- Date: Tue, 10 Jul 2012 18:26:34 +0000
- To: "public-html-media@w3.org" <public-html-media@w3.org>
- Message-ID: <FF4EB51321FAE847A9650D1E9ABB57A440B3C73E@TK5EX14MBXC302.redmond.corp.microsoft.>
HTML Media Task Force Teleconference 10 Jul 2012 The minutes are available in HTML here: http://www.w3.org/2012/07/10-html-media-minutes.html or in plain text, below. ------------------------------------------------------------------------------ Agenda http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0015.html See also: IRC log http://www.w3.org/2012/07/10-html-media-irc Attendees Present suzie, duncanr, +1.858.880.aaaa, johnsim-microsoft, pladd, acolwell, +1.720.934.aabb, BobLund, markw, ddorwin, adrianba, paulc, yang, [Microsoft], glenn, johnsim, BillyWatts, Tom_Handal, Clarke Regrets Chair Paul Cotton Scribe johnsim Contents Topics 1. role call 2. previous meeting minutes 3. review of action items 4. base line documents 5. object oriented api proposals 6. new bugs filed Summary of Action Items <trackbot> Date: 10 July 2012 i can scribe if you provide me the correct instructions thanks i am changing phones <paulc> this conference is media zakim who am i zakim microsoft.a is me <glenn> scribenick: johnsim <Clarke> +Clarke_Stevens <glenn> 720 is colorado ------------------------- 1. role call scribenick johnsim-ms ------------------------- 2. previous meeting minutes <paulc> http://www.w3.org/2012/06/26-html-media-minutes.html <paulc> Noted ------------------------- 3. review of action items ------------------------- 4. base line documents <paulc> Noted ------------------------- 5. object oriented api proposals two bugs 16612, 16613 <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16612 <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16613 <ddorwin> have to dial back in apparently <paulc> IRC FAQ: http://www.w3.org/2001/12/zakim-irc-bot.html <glenn> http://www.w3.org/2002/03/RRSAgent <glenn> http://www.w3.org/2005/06/tracker/irc <adrianba> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0015.html <paulc> API design proposal #1 http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0136.html ddorwin: 136 was based on conversation two weeks ago ... key request generate session object on media element ... didn't address reuse ... reasons for separateing key creation from media elements <ddorwin> separating key creation: http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0134.html ddorwin: with a constructor, not on lifetime of underlying media element, and may help with key release, etc. <paulc> API design proposal #2 (using a MediaKeySession constructor) http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0143.html ddorwin: proposal #2, modification of original proposal, to use a constructor, that seemed to make sense, ... 2b supercedes because 2 would be too hard to implement <adrianba> #2b -> http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0002.html <ddorwin> 2b: http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0002.html eric: 2b, post response in email <paulc> Yang's questions are in: http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0031.html eric: describe for 2b, second proposal makes sense from api point of view. Question: why not associated with media element - add a session - <yang> Why can not, can we use some method like addSession to add a session to a media element? <ddorwin> addSession would not provide "strong association" <yang> The key lookup will happen in CDM, so if we bind a session with a media element, and add key to the session, the key is passed to CDM, there will be no difficulty if only 1 key is needed for decryption, if for multiple keys for the same media element, I think the CDM only need 1 key at the same time to decrypt the media content, we may keep the principle, that 1 session for 1 key, and each time key change, the session removed and recreate, so there will be ddorwin: principle in last meeting, one init data is one session ... when you go to decrypt a frame, you don't have session id so you need to look at all sessions to find the key id sessions mean nothing at time you do a decryption only for key exchange yang: session has multiple keys ddorwin: media element can have multiple sessions ... multiple streams, audio and video using different keys, and you can have key rotations, perhaps on different sessions yang: different tracks - different keys paulc: not only possibility, not obvious what the keys are meant for, not pre-determined ddorwin: CDM would be told what KID to use for a given block and look up in some table and why 2B was for a single table for a media element if all sessions you wanted to use were associated in some way ... proposal 1 had a strong association, but there are limitations, 2 had advantages adrianba: a couple of things in the proposal, perhaps syntax details, aren't quite clear to me. adrianba; media element has media keys object, but then you have the media key interface with a constructor which passes in the key system string and it is not clear how that constructor gets called in the call example, not a (new) instance - key system string a bit like an index ddorwin: the example has a mistake should say new media keys ... not intending to index anything ... unless to create from an element there has to be some sort of assigning. ... get at directions, debate specifics, high level comments, preference for 1, 2, 2b <markw_> 2b looks good to me adrianba: in broad terms, we ... just like we agreed on media source spec the object oriented approach is something we want to do, we should update the spec with this proposal, the 2b proposal is the best one to go with right now <yang> 2 only for key session without collection right? adrianba: more changes, but easier to review when it is in the document <BillyWatts> agreed... 2b seems like a good direction ddorwin: +1 on 2b paulc: we now have 4 ... may take a while to settle it down, but anyone object to starting from 2b ? <yang> +1 on 2b, but need detailed paulc: time to edit? ddorwin: some major rewrites of algorithms, should be able to do it in the next two weeks paulc: best use of our time now is to look at other bugs in the agenda or some other mechanism? ideal to be done in one week to give people chance to review before next call ddorwin: see where we are at the next weeks call ddorwin and the editors have offered to revise based upon proposal 2b <paulc> #2b -> http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0002.html <paulc> ACTION: ddorwin and editors to implement proposal 2b by revising EME specification [recorded in http://www.w3.org/2012/07/10-html-media-minutes.html#action01] <trackbot> Created ACTION-1 - And editors to implement proposal 2b by revising EME specification [on David Dorwin - due 2012-07-17]. at the media source meeting next week spend a minute to see where we are with the update to EME ------------------------- 6. new bugs filed paulc: in order of agenda <paulc> [Bug 17615] New: Support for different CDM communication models https://www.w3.org/Bugs/Public/show_bug.cgi?id=17615 adrianba: request in this bug is to support the model where the decoding is part of the media element and we actually have a separate <paulc> Separate bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16543 adrianba: bug, 16543, based on feedback from david singer, who pointed out that it is already possible with html5 to take care of content protection without any additional spec ... make changes to introduction for programmatic support for interacting with the content protection module and make it explicit that you can already do this in the media element ... proposed resolution, is to close it, as 'works for me' <paulc> Proposed status is WORKSFORME with no changes Yang; for this bug, two different CDM models, i noticed, UA and the CDM, it is not a javascript api <adrianba> +1 - this is an implementation detail in the browser <yang> and the retrieveKey does not need to be defined in W3C, it is not a JS API.? paulc: editors should take action on this bug ... next 17658 <paulc> [Bug 17658] New: need procedure for selection of Key System https://www.w3.org/Bugs/Public/show_bug.cgi?id=17658 Yang: no clear discripion of how UA detects Key System <yang> f 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, but in "jump to Key Presence", we are handling key already exist, so why before key system selected, we can have key? We may need let a ddorwin: mark and i replied. anything still unclear after the email and bug reply? <paulc> See replies including: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17658#c3 ddorwin: important part, UA never selects the key system, application selects ... with common encryption , you may need key system specific data in the file, but that is a separate issue paulc: Yang, are you satisfied by the answer - UA does not pick the key system? ... if something missing in the algorithm, should suggest text. yang: discuss offline in email <scribe> ACTION: continue bugzilla and email discussion of 17658 [recorded in http://www.w3.org/2012/07/10-html-media-minutes.html#action02] <trackbot> Sorry, couldn't find user - continue paulc: next 17660 <paulc> [Bug 17660] New: need token relative with user identity for a new generateKeyRequest parameter https://www.w3.org/Bugs/Public/show_bug.cgi?id=17660 paulc: comments? ddorwin: user identify in generate key request, perhaps part of license request, the thinking in the current proposal combine with init data ... so this is handled by the current specification and trying not to add any other features but open to discussion yang: token outside of init data, perhaps downloaded from web server, token can passed to the CDM with the init data and other things ddorwin: the application can combine token with init data in the current APIs, so looking for comment if explicit parameter like you propose is something people are interested in adrianba: when we talked about this topic before original proposal, lots of different options for various data we might want to supply here, user token, or something in the applicaiton andrianba: and ended up saying init data is a large block of data, a binary blob of data, we will need some more implementation experience to determine if that is the most appropriate whaay of doing this adrianba: need to make more progress and experience/implementation before proposing that. so recommend you can combine in an application-specific way into init data and if we decide ... that is too complicated we can change the api paulc: how to dispose of this bug. held for now? until we have more implementation experience? adrianba: we could resolve it like that. yang: okay, we can hold for now paulc: Editors to resolve as "will not fix" for now, it will be easy to re-raise if experience indicates a single binary blob is not meeting the use cases Summary of Action Items [NEW] ACTION: continue bugzilla and email discussion of 17658 [recorded in http://www.w3.org/2012/07/10-html-media-minutes.html#action02] [NEW] ACTION: ddorwin and editors to implement proposal 2b by revising EME specification [recorded in http://www.w3.org/2012/07/10-html-media-minutes.html#action01] [End of minutes] -------------------------------------------- John C. Simmons | Media Platform Architect | Microsoft Corporation | direct 425-707-2911 | mobile 425-269-5759
Received on Tuesday, 10 July 2012 18:27:17 UTC