15:43:42 RRSAgent has joined #html-media
15:43:42 logging to http://www.w3.org/2013/01/15-html-media-irc
15:43:44 RRSAgent, make logs public
15:43:44 Zakim has joined #html-media
15:43:46 Zakim, this will be 63342
15:43:46 ok, trackbot; I see HTML_WG()11:00AM scheduled to start in 17 minutes
15:43:47 Meeting: HTML Media Task Force Teleconference
15:43:47 Date: 15 January 2013
15:44:14 Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0016.html
15:44:18 Chair: Paul Cotton
15:59:34 pal has joined #html-media
15:59:38 paulc has joined #html-media
16:00:17 HTML_WG()11:00AM has now started
16:00:25 +[Microsoft]
16:00:33 zakim, [Microsoft] has adrianba, paulc
16:00:33 +adrianba, paulc; got it
16:00:46 +pal
16:01:26 acolwell has joined #html-media
16:01:48 +Aaron_Colwell
16:02:47 +[Microsoft.a]
16:02:51 + +1.425.202.aaaa
16:02:54 ddorwin has joined #html-media
16:03:01 chriho has joined #html-media
16:03:03 zakim, aaaa is me
16:03:03 +johnsim; got it
16:03:10 MartinSoukup has joined #html-media
16:03:53 zakim, johnsim is ddorwin
16:03:53 +ddorwin; got it
16:04:01 zakim, [Microsoft.a] is johnsim
16:04:01 +johnsim; got it
16:04:17 zakim, who is on the phone?
16:04:17 On the phone I see [Microsoft], pal, Aaron_Colwell, johnsim, ddorwin
16:04:19 [Microsoft] has adrianba, paulc
16:04:44 +Mark_Watson
16:04:47 BobLund has joined #html-media
16:05:15 ScribeNick: adrianba
16:05:19 Scribe: Adrian Bateman
16:05:34 Topic: Role call, introduction, selection of scribe
16:05:36 paulc: done
16:05:50 +[Microsoft.a]
16:05:55 Topic: Previous meeting minutes
16:05:57 http://www.w3.org/2013/01/08-html-media-minutes.html
16:06:00 paulc: no comments
16:06:05 markw_ has joined #html-media
16:06:12 Topic: Review of action items
16:06:16 paulc: none for MSE
16:06:23 Topic: Baseline documents
16:06:28 zakim, who is on the phone ?
16:06:28 On the phone I see [Microsoft], pal, Aaron_Colwell, johnsim, ddorwin, Mark_Watson, [Microsoft.a]
16:06:31 [Microsoft] has adrianba, paulc
16:06:41 EME -> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
16:06:54 paulc: lower in the agenda you'll see candidate FPWD
16:07:16 MSE -> http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
16:07:29 paulc: last updated jan 4
16:07:30 + +1.303.661.aabb
16:07:43 TOPIC: Progression to First Public Working Draft
16:07:44 zakim, aabb is me
16:07:44 +BobLund; got it
16:07:58 paulc: CfC is here http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0005.html
16:08:02 ... closes tomorrow
16:08:30 ... chairs have assigned me the task that if it passes we'll move to the stage of trying to publish the document as FPWD
16:08:40 ... only thing we need to decide is short name
16:09:07 ... we've proposed media-source
16:09:17 ... it just needs to be unique
16:09:33 ... we have to send a transition request to the chairs list and the W3C Team on behalf of the Director responds
16:09:43 ... one of the proforma things we have to do is give them the short name
16:09:57 ... as well as links to document, status, decision, etc.
16:10:25 ... you should expect to see a note from me and the editors will see a note suggesting to work with Mike Smith to get it published
16:10:35 paulc: next is the EME spec
16:10:44 ... we discussed 4 items that needed addressing
16:11:20 ... bug 17199 - proposal http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0011.html
16:11:27 ... has that been implemented?
16:11:41 markw: discussion with David and proposed a different approach
16:12:12 ... if we take this different approach outlined in David's mail then it needs some different changes
16:12:42 paulc: just reviewing the thread - you add 20622
16:12:50 markw: i think this is a minor issue
16:13:28 paulc: what does the group want to do - one of the items is not done
16:13:33 ... candidate FPWD -> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html
16:13:42 ... do we want to wait, or push this aside
16:13:59 markw: if the group agrees with the general approach then we could get the text worked out today
16:14:07 ... which could be the basis for the CfC
16:14:30 paulc: adrian mentioned it took a lot longer to prepare for pubrules than expected
16:14:50 ... hopefully none of that will be regressed
16:15:23 ... so the proposal is to take the results of the thread and add that to the candidate FPWD
16:15:45 ddorwin: the last mail about null, etc. still needs some thinking about
16:15:54 q+
16:15:54 ... there may be other uses cases for null
16:16:14 ... i attached a patch with async session id, etc
16:16:32 ... there is already a key release section in the doc
16:16:46 ... we don't expect that FPWD is completely implementable
16:16:57 ... i don't see a problem with going with what we already have
16:17:12 ... if we don't decide on this call then when will we decide
16:17:29 paulc: you outlined some additional problems and then questioned whether 17199 is a blocker
16:17:30 q?
16:17:37 ack next
16:17:59 markw: on the technical issue on the use of null - we don't say that is specifically retrieved to key release
16:18:22 ... null would retrieve any session that was stored for whatever purpose
16:18:46 ... i do think we should try to address this with the original proposal or David's revised proposal
16:19:16 paulc: not sure what to do - perhaps we should go on and see if there are any other blockers
16:19:27 markw: can we fix this today and go for CfC tomorrow?
16:19:45 paulc: i'm okay with what you're proposing if everyone else is clear and it's clear what the mandate is
16:20:16 ... little uncomfortable with two people are going to fix the bug - would prefer will fix the bug in a specific way so that CfC can say we will take the candidate FPWD plus this change forward to the WG
16:20:30 My proposal would be: (i) adopt David's proposed changes to createSession() ...
16:20:41 ... do you think you have enough confirmed? if not then probably means a week delay
16:20:43 q+
16:20:44 (ii) address asyncronous assignment of sessionId
16:21:03 (iii) specify a way to retrieve persisted sessions
16:21:08 ddorwin: latest email is open ended about persistent sessions - think it would be hard to be specific
16:21:21 ... don't think it's as simple as just adding some text
16:21:23 ack next
16:23:04 adrianba: think the goal of FPWD is to set scope and the section is in the document
16:23:18 ... we should move ahead with what we have and then fix the bug
16:23:34 markw: i think what we said was we wanted this in the FPWD
16:23:44 ... i'd prefer this even if there is a one week delay
16:24:16 ddorwin: i think we have it covered as an issue, don't think anyone will implement as FPWD, new proposal is simpler and not a lot of algorithms needed
16:24:20 q?
16:24:20 q+
16:24:27 ack next
16:24:51 acolwell: seems to me that we don't have agreement so it sounds like we need another week - doesn't seem like we'll get to the decision - we should move on
16:25:10 paulc: next bug is 17682 - not clear what had happened
16:25:21 ACTION-9?
16:25:21 ACTION-9 -- John Simmons to discuss 17682 with markw and propose text for JSON solution -- due 2012-12-18 -- OPEN
16:25:21 http://www.w3.org/html/wg/media/track/actions/9
16:25:38 johnsim: this work was done
16:25:44 ... i submitted the changes in the bug
16:25:54 ... this was incorporated into the candidate FPWD
16:27:00 paulc: next is 18531 - believe this is done
16:27:19 ... next is 20335 - adrian was supposed to do this week
16:27:35 ... bug is still open because as noted by david there is still an open question about 2 states being enough
16:27:40 ... don't propose we discuss now
16:27:43 ... bulk is done
16:28:13 paulc: so i believe we have a candidate working draft that covers 17682, 18531 and most of 20335
16:28:28 ... we still have 17199 and the new bug 20622
16:28:30 https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html
16:28:51 paulc: sounds like the best consensus that causes least amount of dissent is to give TF one more week to flatten the remaining bugs
16:29:04 ... and get a new candidate FPWD by next week
16:29:20 ... editors should expect a one week delay
16:29:40 ddorwin: what happens if we're not in agreement by next week on this issue?
16:29:59 paulc: in a consensus based organisation like w3c it is hard to anticipate all eventualities
16:30:23 ... if you can't reach agreement then need to bring the questions out onto the mailing list ASAP and people need to propose alternate ways of solving
16:31:10 q+
16:31:24 ... maybe get an agreement on how to mark-up the document that identify the areas of contention (we did this with MSE and included pointers to bugs that people felt were important)
16:31:36 ... it's okay to publish FPWD with one or more health warnings in it
16:31:37 q?
16:31:50 ack next
16:32:07 markw: i think david's proposal is a good one - i mentioned three items in IRC earlier
16:32:23 ... you said first 2 were straightforward and last was more controversial
16:32:39 ... think those are the only things necessary
16:32:56 paulc: one possible solution is to get first 2 done and separate mail or bug on third item
16:33:10 actually there is (iv) FAQ text, but I hope we can re-purpose text
16:33:23 paulc: could you live without part 3
16:33:29 markw: let's see if we get there
16:33:48 paulc: leave EME at this point
16:34:04 pal_ has joined #html-media
16:34:07 ... david and mark have the task to get us a revised document
16:34:22 TOPIC: Media Source Extensions bugs
16:34:31 paulc: Aaron started two mail threads with items to discuss
16:34:45 paulc: Rethinking MediaSource.setTrackInfo() and MediaSource.getSourceBuffer()
16:34:51 http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0007.html
16:35:18 acolwell: this is suggesting that we replace these methods with modifying the underlying HTML objects for the tracks to make it seem more natural
16:35:26 ... propose to specify them in the media source draft
16:35:41 ... after CfC I was contacted by a couple of people about how they work
16:35:50 ... wanted to propose that we rethink it
16:36:17 ... to do something more natural not constrained by HTML spec process
16:36:23 ... are people okay with these changes
16:36:32 paulc: does this attach us more directly to the HTML spec?
16:36:56 acolwell: no, it takes the existing HTML track objects and we're going to redefine two attributes and add another
16:37:11 ... if an implementation supports MSE then it adds these changes on
16:37:29 ... main change is kind and language are read-only in HTML spec - here we make them writable
16:37:56 ... we just have these in the MSE spec - if HTML.next decides to make these writable in the future they can just use our definitions
16:38:48 paulc: the last item you pointed out was if we publish a doc with these writable - maybe we file a HTML 5.1 bug to make them mutable since one extension works
16:39:02 acolwell: not sure if this will always be a separate document
16:39:10 ... filing the bug would make sense
16:39:40 paulc: any other questions?
16:41:16 bug 17002 and bug 17006
16:41:22 acolwell: should i change the fpwd?
16:41:35 paulc: no, i don't think so - let's work on getting a future draft out
16:42:11 q+
16:42:27 markw has joined #html-media
16:42:38 ack next
16:42:55 adrianba: either reopen existing bugs or new bugs with a link to the old ones
16:43:07 paulc: my preference is to reopen
16:44:04 acolwell: do we have agreement that this is the right solution?
16:44:12 paulc: i haven't heard anyone complain about this
16:44:13 q?
16:44:21 paulc: anyone have a problem with this?
16:44:39 paulc: going to assume people are okay with this
16:44:43 +1
16:44:56 paulc: go ahead and get this into the editor's draft
16:44:58 acolwell: ok
16:45:16 paulc: next is Bug 18615 - HTMLMediaElement.buffered behavior in "ended" state
16:45:30 acolwell: this one is tricky and not sure how to proceed - really looking for input at this point
16:45:51 ... variety of problems with appending sections and when you call end of stream you might have segments with gaps
16:46:02 ... as well as tracks with significantly different lengths
16:46:16 ... need to be some clarity about what to do - don't usually get this situation with media in files
16:46:34 ... right now the spec does this hand wavey thing where it only considers the last buffered range
16:46:50 ... and if playback is in last buffered range then will play through to the longest
16:46:59 ... but what happens if there is a gap and end of stream was called
16:47:02 q+
16:47:24 ack next
16:47:53 markw: just writing some answers and assumed end of stream was on sourcebuffer but it is on media source not on the buffer so you can specify they end at different times?
16:48:07 acolwell: assume end of stream is a global state for playback
16:48:17 ... so calling it is the signal that you're not going to append any more data
16:48:34 markw: i think if the signal is that the latest data is the final one in that track
16:48:58 ... we allow out of order appends but end of stream could mean this buffer gets no longer
16:49:04 ... you could go back and fill in gaps
16:49:18 acolwell: but what is playback supposed to do with gaps?
16:49:34 markw: same as it always would - it would stall waiting for you to fill in the gap
16:49:49 acolwell: then i don't see the different between a global and per buffer end of stream
16:50:10 markw: the difference is the global one means i have to append every last frame for every buffer
16:50:32 ... which means playback could get to the end of a buffer and stall because you haven't said yet that it is the end
16:50:56 q?
16:51:22 paulc: mark, did you send this in mail?
16:51:30 markw: not yet - half way through writing it
16:51:37 acolwell: please send to the list - need to think some more
16:51:51 paulc: any other bugs you wanted to pick up on?
16:52:00 acolwell: meant to send mail on this other one:
16:52:27 ... https://www.w3.org/Bugs/Public/show_bug.cgi?id=18592
16:52:35 ... How much is "enough data to ensure uninterrupted playback"
16:53:08 acolwell: main issue is event have enough data - concern by philip that because there is no way for UA to know if it has enough data to play through to the end
16:53:28 ... he was suggesting that the readystate never transition to enough data and always stay in future data
16:53:34 ... this means autoplay will not work
16:53:44 ... i want to know if the group accepts that
16:53:58 ... i don't think it is acceptable because people will be surprised by autoplay not working
16:54:11 q+
16:54:20 ... we need to reinterpret how to know if it can play through to the end
16:54:27 ... interested in other opinions
16:54:30 ack next
16:55:12 BobLund: to me it seems intuitive the other way - not having autoplay would be okay since script is necessary - doesn't seem like a stretch to say it script knows when to play
16:55:33 acolwell: for someone building a player library on top of media - shouldn't need to know where the data came from
16:55:47 ... that's where i thought it might be surprising that it doesn't work
16:56:13 BobLund: in that scenario it seems like the functions doing the filling of the sourcebuffer have the best information about when play can start
16:56:22 ... so maybe the library determines when play begins
16:56:25 acolwell: ok
16:56:43 ... the other reason to go between ENOUGH and FUTURE for the UA to be able to signal when it needs more data
16:57:23 ... if ENOUGH means the UA is happy with the data it has and if the amount gets too low the UA could go to FUTURE and then the app knows it isn't filling fast enough
16:57:32 ... that does stray from HTML5 definitions though
16:57:37 paulc: anyone else?
16:57:46 ... is that a conclusion?
16:58:07 acolwell: i could remove it - still want to know what others think
16:58:16 adrianba: i'd like more time to review with our team
16:58:40 paulc: given there has been no email discussion - think you should send out mail and we can pick this up either in mail or at the next meeting
16:59:20 acolwell: relatively small spec change but significant to web developers
16:59:31 paulc: okay, think we're done for today
16:59:42 ... most significant action is to get EME bug finished
16:59:50 ... next week we'll start with EME FPWD discussion
16:59:58 ... would be useful to queue up some other items for discussion
17:00:40 acolwell: one other question - when CfC is done, what needs to be done on editor's side
17:00:56 paulc: you'll see private email to editors copying Mike Smith
17:01:12 ... basically Mike runs document through pubrules and coordinate if there is extra work to be done
17:01:28 ... could send mail right now - say it is in CfC
17:01:44 adrianba: i can cover this while you're away
17:01:45 -BobLund
17:01:48