- From: Joe Steele <steele@adobe.com>
- Date: Tue, 28 Jan 2014 17:14:59 +0000
- To: John Simmons <johnsim@microsoft.com>, "<public-html-media@w3.org>" <public-html-media@w3.org>
- Message-ID: <5FAD5B52-ED47-432A-AEAA-35A4741DC53A@adobe.com>
Please review and reply with any corrections. http://www.w3.org/2014/01/28-html-media-minutes.html Joe Steele HTML Media Task Force Teleconference 28 Jan 2014 Agenda See also: IRC log Attendees Present paulc, markw, +1.425.269.aaaa, joesteele, adrianba, ddorwin, davide, JamilEllis, pal, BobLund, johnsim Regrets Chair paulc Scribe joesteele Contents Topics Role Call Action Items high priority items Heartbeat Bug#17673 bug#24027 bug#23619 bug#24025 bug#24216 bug#24081 bug#24323 bug#18515 bug#24368 bug#24381 New Business Summary of Action Items <trackbot> Date: 28 January 2014 <paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0059.html <scribe> ScribeNick: joesteele Role Call Action Items ACTION-48? <trackbot> ACTION-48 -- Adrian Bateman to Draft a proposal for bug 17673 -- due 2014-01-27 -- OPEN <trackbot> http://www.w3.org/html/wg/media/track/actions/48 adrianba: We agree with David on using the content type string <paulc> See Ade's update at https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673#c38 adrianba: need some more discussion in the task force close ACTION-48 <trackbot> Closed ACTION-48. paulc: let's close then ACTION-61? <trackbot> ACTION-61 -- Paul Cotton to Work with wendy to make sure we get a security review of eme -- due 2013-12-10 -- OPEN <trackbot> http://www.w3.org/html/wg/media/track/actions/61 <paulc> lates is at htp://lists.w3.org/Archives/Public/public-html-media/2014Jan/0056.html paulc: followed up with Wendy <paulc> latest is http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0056.html paulc: still pending ACTION-62? <trackbot> Action-62 -- Paul Cotton to Report back about the plan for 20944 due 2013-12-15 -- due 2013-12-10 -- OPEN <trackbot> http://www.w3.org/html/wg/media/track/actions/62 paulc: still pending ACTION-63? <trackbot> action-63 -- John Simmons to Provide a proposal for bug 24207 to define the shape of cleankey pssh boxes -- due 2014-01-28 -- OPEN <trackbot> http://www.w3.org/html/wg/media/track/actions/63 <wseltzer> [We have a potential reviewer in the WebSec IG; I'll follow up by email.] paulc: on John Simmons <adrianba> i think this is 24027 johnsim: not on computer yet -- in a few minutes high priority items Agenda #5 Heartbeat paulc: David original email proposed we look at this list before heartbeat discussion ... what should we do about a heartbeat? ... doesn't sounds like either of these will be easily closed <adrianba> http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0062.html adrianba: sent an email this morning with bugs needing action from oldest to newest ... agree we won't close them all quickly, but we have made substantial progress since last heartbeat ... fall into the trap of trying to close those that are most desirable, but should not block publication <paulc> +100 paulc: agree completely <paulc> David's priority items email: http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0015.html ddorwin: that's fine -- these are just the most important, but we have published more incomplete drafts paulc: then this is the current draft <paulc> Current editor's draft: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html paulc: is that draft ready to go? candidate heartbeat? ddorwin: yes, just one typo paulc: how should we proceed then? since you did not know this was coming don't want to force <adrianba> +1 paulc: is the group ready to forward this as a publication? ... any objections? <ddorwin> +1 joesteele: none from me -- +1 to publishing paulc: ok David, please make the editorial changes and move to location that won't change further ... suggest you publish by Feb 6th if you can get it done today ... do we need to look at the status section? ... 20944 is mentioned - probably still not finalized ddorwin: correct, some cleanup but nothing that affects this section paulc: is there a changelog in this doc? <adrianba> changelog is in mercurial paulc: nothing to tell a reader what has changed since Sept 2013 -- that's a long time ... suggest we just publish as is with editorial changes <markw> ok with me paulc: back to agenda Bug#17673 <paulc> Next ACTION: TF to discuss David's proposal that Microsoft supports to change the string associated with needkey/createSession paulc: Adrian your email with recommendations came late so did not print -- can I use in the notes? adrianba: two related issues - may need to separate <paulc> Ade's update is at https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673#c38 adrianba: 1. when you fire a needKey you provide a string which tells you the format of the initData, used when you call createSession ... so we have been discussing making simpler by indicating that "this is common encryption" which defines the format as a series of PSSH boxes ... this simplifies the specification, because otherwise we would require implementations to do something more complex because MP4 allows for more options ... 2. even if we move forward with TPAC plan, problem with applications using isTypeSupported since you can't guarantee until you have tried it ... possible to support the keySystem and the container and still not be able to play without more information ... think they are related but not sure whether we need to separate them ... good to get feedback from player implementers ddorwin: in parallel I have been thinking that isTypeSupported is insufficient, will file a bug when I get around to it, otherwise I agree paulc: can we resolve by carving off that item? ddorwin: adrian is looking for feedback adrianba: would be good to get David Singers review paulc: so you did not work with him yet? adrianba: if you look at what we did with MSE think we should move the definitions outside of this spec, an informal registry, this string would map to one of those definitions ... one for WebM, one for CENC, etc ... so what would you do if you want a SINF would be relevant ... if you did try to playback something requiring SINF when only CENC is supported, get back the same error as isTypeSupported ... not sure how specific we want the error result to be markw: if we want to provide full capabilities, not just container and decryption, its also codec and keySystem ... do we actually need more MIME type parameters? ... more granualar adrianba: agree with what Mark said about the features matching to the capabilities, I mentioned these in the bug as well ... using an enhanced content type string with other parameters might be a way to go, but the potential downside is that we have to generate from the needKey event ... so we have to think through what we want to do ... i.e. create the string which is video/mp4 and then the string which is added for the codec and for the type of encryption, maybe something else ... starts to become an awkward string to create ... might not be the best approach pal: what about taking the registry approach where we register the format combination of video, codec e.g. like CFF Ultraviolet ... the value used signals compliance with the specification includes codec, encryption, etc. is that an option <pal> video/vnd.dece.mp4 <markw> @adrian: I think creating such a string would be merely tedious rather than awkward: video/mp4;codec=avc1.xx.xx;keysystems=<uuid>,<uuid>,<uuid>;protection=cenc pal: just exploring avoiding parameterize all combinations paulc: have heard two actions -- more on agenda ... one is for David to split off the issue Adrian described ... second is for folks to look at Adrians proposal and also engage David Singer <adrianba> markw, but then the consumer has to parse the data back out again and so we end up with lots of people writing encoders and parsers for this string <adrianba> markw, perhaps that is defined as tedious - i wonder if there is a better way is all <paulc> Item for David to split off is about whether isTypeSupported is insufficient <paulc> Item for Adrian is to ask David Singer to review https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673#c38 <ddorwin> MIME type, including codec= and profile= is defined by an RFC. We shouldn't mess with that string bug#24027 paulc: this has action-63 pending ... Adrian you said there is a proposal made by Pavel <ddorwin> initData format should be a different parameter/attribute <paulc> ACTION-63? <trackbot> ACTION-63 -- John Simmons to Provide a proposal for bug 24207 to define the shape of cleankey pssh boxes -- due 2014-01-28 -- OPEN <trackbot> http://www.w3.org/html/wg/media/track/actions/63 <paulc> Next ACTION: ACTION-63 on John to make proposal - there has been a proposal made by Pavel with comments from David <ddorwin> I'm not sure we need the MIME type in all places we need protection <adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24027#c2 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24027 <paulc> Pavel's proposal: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24027#c2 paulc: do you believe this makes Johns action item moot? adrianba: assume John will want to review johnsim: this is inline with what I was thinking paulc: free to mark as closed and leave a link to what you did bug#23619 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23619 paulc: since we are going ahead with the heartbeat this is no longer blocking ddorwin: implemented this yesterday ... deleted all the error codes and replaced with names ... but was wondering do we really need this <paulc> See David's question in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23619#c8 ddorwin: MediaError is inherited from DomError -- do we really need the system code or just use DomError since it is just a message <ddorwin> https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#error-codes ddorwin: if it is mainly for debugging <ddorwin> ^updated yesterday adrianba: read the comments, haven't had time to ponder deeply yet, need to discuss ... initial thinking is that message is intended to be something you can display ... you could construct a message and include additional error code ... this might be ok ... you capture the whole string and then you would need to parse it somewhere ... did not know whether there are cases where people look at the system code to determine whether to try again ... having it in a message might make it harder to access ... understand the proposal but just wonder whether this is the right thing for practical implementations, since some apps will have dependencies ddorwin: if it is used for switching, makes sense to have a code, but said it would make more sense for logging ... easy to switch to DomError which would make that easier paulc: could look at new bugs or try to scan bugs with proposal and discuss ones that make sense ... ok to skip new bugs? ... hearing no objections bug#24025 <paulc> Latest from DEc: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23619#c8 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24027 paulc: its 24025 <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24025#c6 ddorwin: no progress, tied to the general extensibilty issue bug#24216 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24216 <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24216 ddorwin: there is tl;dr at the top -- no replies yet jdsmith: I was not certain about the scenarios, would like comments from John Simmons on this <paulc> Ade's reply: Next ACTION: TF needs to review and discuss - I know Jerry is looking at this for Microsoft and waiting for feedback internally jdsmith: attaching and removing keys is important to this bug <ddorwin> Suggest next topic be: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c19 bug#24081 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24081 paulc: proposal from Jan 18th <paulc> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=24081#c4 paulc: Adrian got a reply, Marks got a reply ... anyone else ... any more comments or review needed? joesteele: looks good to me paulc: shall we ask David to implement? ... have 4 supporters -- please add to your list David bug#24323 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24323 <paulc> No responses yet. ddorwin: we were trying to decide whether needKey should be fired - renamed the algorithm -- but not sure the name is appropriate anymore <paulc> Ade's status: Next ACTION: Feedback needed from TF ddorwin: other issue is that the spec currently allows you to detect that a stream is encrypted whether or not initData is available ... not true for WebM or BMFF or CENC ... want to change alg to say initData indicates potentially encrypted stream and to fire needkey with that initData paulc: move on bug#18515 https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515 paulc: where does this stand? ... reply from Jerry to at least one of Davis responses <paulc> See proposla in https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c19 paulc: latest is a fairly detailed proposal ddorwin: fine with this, we should implement and review from there paulc: so add this to the list if no objections ddorwin: assign to Adrian? Jerry can pick an editor bug#24368 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24368 paulc: related to 18515 ... is this an actual proposal? ... comment #1 <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24368#c1 ddorwin: think I answered my own question but would like feedback ... appears to be covered by MSE and HTML5 but not very explicit - might be a bug ... could add a line to Jerrys proposal in the bug paulc: this is assigned to Adrian ... best plan is to have 18515 editor to look at this as well adrianba: not assigned to anyone yet ddorwin: if Jerry wants to include this that would be fine jdsmith: I will review <paulc> Bug 24368 - Define playback behavior when the key for an encrypted block is not available for a subset of streams https://www.w3.org/Bugs/Public/show_bug.cgi?id=24368 paulc: on the agenda twice -- let me look paulc: let’s skip bug#24381 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24381 joesteele: looks like an editorial change? <paulc> Already covered. See above. <paulc> [Bug 24381] New: HTMLMediaElement.setMediaKeys() appears superfluous <paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24381 paulc: filed by Phillip adrianba: believe we have discussed this but have not had time to find it ... discussed a long time ago paulc: any more evidence offered? adrianba: don't agree with the proposal but need to find the old bug paulc: think we have covered the agenda New Business paulc: I believe we have a couple of MSE bugs ... don't want to convene specifically to cover these bugs, but wanted editors to know there are some CR bugs ... filed by Phillip adrianba: might be implementation experience from Aaron paulc: will wait until we have more than 1 or 2, continue with EME for now <paulc> MSE bug re WebIDL: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24370 paulc: in two weeks (Feb 11th) I am on vacation -- what does the group want to do? <ddorwin> One more EME new bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24419 paulc: could make up the agenda before I go and pick another chair johnsim: sure paulc: that is what I will do then ... we can pick some items to go over, appreciate advice from the editors <adrianba> thanks paul Summary of Action Items [End of minutes] Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log) $Date: 2014-01-28 17:10:57 $
Received on Tuesday, 28 January 2014 17:15:31 UTC