{minutes} HTML WG media telecon 2014-01-28 - EME Status

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 $