14:52:47 RRSAgent has joined #html-media
14:52:47 logging to http://www.w3.org/2013/07/23-html-media-irc
14:52:49 RRSAgent, make logs public
14:52:49 Zakim has joined #html-media
14:52:51 Zakim, this will be 63342
14:52:51 ok, trackbot; I see HTML_WG()11:00AM scheduled to start in 8 minutes
14:52:52 Meeting: HTML Media Task Force Teleconference
14:52:52 Date: 23 July 2013
14:56:58 pladd has joined #html-media
14:57:11 ReimundoGarcia has joined #html-media
14:57:32 JamilEllis has joined #html-media
14:58:16 HTML_WG()11:00AM has now started
14:58:20 Michael_Thornburgh has joined #html-media
14:58:23 +pladd
14:58:42 +??P9
14:58:50 zakim, ??p9 is me
14:58:50 +glenn; got it
14:58:57 + +1.831.457.aaaa
14:59:04 zakim, i am aaaa
14:59:04 +Michael_Thornburgh; got it
14:59:22 stevep has joined #html-media
15:00:19 + +1.650.458.aabb
15:00:37 Zakim, who is on the phone?
15:00:38 On the phone I see pladd, glenn, Michael_Thornburgh, +1.650.458.aabb
15:00:53 adrianba has joined #html-media
15:00:54 +ReimundoGarcia
15:00:59 + +44.173.776.aacc
15:01:10 paulc has joined #html-media
15:01:28 pal has joined #html-media
15:01:32 jdsmith has joined #html-media
15:01:45 acolwell has joined #html-media
15:01:47 +[Microsoft]
15:01:53 +[Microsoft.a]
15:01:57 zakim, [Microsoft] has me
15:01:57 +paulc; got it
15:02:11 +Aaron_Colwell
15:02:46 Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Jul/0013.html
15:04:27 zakim aacc is me
15:04:54 +[Microsoft.aa]
15:04:59 zakim, who is on the phone?
15:04:59 On the phone I see pladd, glenn, Michael_Thornburgh, +1.650.458.aabb, ReimundoGarcia, +44.173.776.aacc, [Microsoft], [Microsoft.a], Aaron_Colwell, [Microsoft.aa]
15:04:59 zakim, [Microsoft.aa] is me
15:05:00 BobLund has joined #html-media
15:05:02 [Microsoft] has paulc
15:05:02 +adrianba; got it
15:05:28 zakim, i am aabb
15:05:28 +pal; got it
15:05:29 zakim, [aabb] is pal
15:05:30 sorry, paulc, I do not recognize a party named '[aabb]'
15:05:34 ScribeNick: adrianba
15:05:38 Scribe: Adrian Bateman
15:05:42 Chair: Paul Cotton
15:05:51 TOPIC: Roll call, introductions and selection of scribe
15:06:07 zakim, stevep is aacc
15:06:07 sorry, paulc, I do not recognize a party named 'stevep'
15:06:15 zakim, aacc is stevep
15:06:16 +stevep; got it
15:06:27 zaki, aabb is pal
15:06:34 zakim, aabb is pal
15:06:34 sorry, paulc, I do not recognize a party named 'aabb'
15:06:35 zakim, who is on the phone?
15:06:35 On the phone I see pladd, glenn, Michael_Thornburgh, pal, ReimundoGarcia, stevep, [Microsoft], [Microsoft.a], Aaron_Colwell, adrianba
15:06:37 [Microsoft] has paulc
15:06:53 paulc: done
15:06:58 Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Jul/0013.html
15:07:05 TOPIC: Previous meeting minutes
15:07:15 + +1.303.661.aadd
15:07:20 paulc: don't think they need any discussion - used to drive the agenda
15:07:26 zakim, aadd is me
15:07:26 +BobLund; got it
15:07:52 TOPIC: Review of action items and issues
15:07:58 paulc: all in the agenda
15:08:11 TOPIC: Media Source Extensions editor's draft
15:08:13 https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
15:08:26 paulc: updated once by aaron on july 18 - sent a note about changes
15:09:40 TOPIC: Pre-Last Call bugs
15:09:45 http://tinyurl.com/6pdnzej
15:10:13 paulc: divided bugs between pre-last call bugs and then last call - if we have time we'll look at the candidate last call bugs
15:10:22 TOPIC: Bug 22137 - changes in number of audio tracks during advert insertion
15:10:26 ACTION-21?
15:10:27 ACTION-21 -- Adrian Bateman to work with Jerry to review bug 22137 and provide feedback -- due 2013-07-02 -- CLOSED
15:10:27 http://www.w3.org/html/wg/media/track/actions/21
15:10:33 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137#c8
15:10:37 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137
15:11:29 paulc: comments suggest won't fixing?
15:11:44 acolwell: yes, i'm proposing that we create a different spec to handle track switching independently
15:11:53 ... so that other html5 media can take advantage of it
15:12:05 ... the comments after comment 8 talk about what situations could arise
15:12:29 ... my position is that i agree there could be problems but we should make this another spec because it is an independent issue
15:12:38 ... agree with adrian's earlier comment suggesting marking as Won't Fix
15:12:49 i'm on the phone too
15:12:52 paulc: one of the correspondents is Michael_Thornburgh
15:12:59 ... do you want to make comments?
15:13:12 Michael_Thornburgh: my concerns is mostly making sure the use case is addressed
15:13:25 ... if the solution is another spec to make it possible that's okay
15:13:38 ... i'm particularly concerned that the stalling behaviour is part of the MSE spec
15:13:48 ... and you want to avoid stalls at append time
15:14:23 ... if in some proposed solution in a different spec that allows for timed track switching, this correctly maps to append time stalling behaviour then that would be okay
15:14:43 acolwell: my intention was that MSE talks about what tracks are taking into account during playback
15:14:52 ... so stalls only happen if tracks playing don't have content
15:15:07 ... this other proposed mechanism would specify when the switch happens
15:15:21 ... and track switch would happen as if they were being done instantly
15:15:35 ... but because you provide the data ahead of time, the media engine knows a switch is coming up
15:15:56 ... however that spec addresses switching then it will allow for a window around the switch where it doesn't have to match exactly
15:16:05 Michael_Thornburgh: that sounds reasonable
15:16:05 is this great information provided by Aaron captured somewhere in the specification?
15:16:46 acolwell: to pal's question, how stalls happened and what happens when a track is enabled or disabled is in the spec
15:17:04 ... so this new spec would specify a track switch in terms of how tracks currently are enabled or disabled
15:17:10 ... so MSE would work with that
15:17:29 ... tracks enabled get added to active source buffers and affect stalling
15:17:31 +q
15:17:40 ack Michael
15:17:42 ... when removed gets removed from active source buffers and doesn't have to have data for playback
15:18:08 Michael_Thornburgh: the other issue is having more than two sourcebuffers
15:18:50 ... probably ought to be some indication in the spec that sourcebuffers > 2 should be supported
15:18:51 q+
15:19:01 acolwell: i have concerns about mandating that
15:19:05 q+
15:19:05 ack ad
15:19:14 q+
15:19:18 ack ac
15:19:19 adrianba: IE11 supports more than two sourcebuffers
15:19:27 q+
15:19:40 acolwell: i have concerns about specifying how many need to be supported - this is a quality of implementation issue
15:19:45 ... don't need to put this in the spec
15:19:45 ack pal
15:20:05 pal: section 2.2 requires 3 source buffers, right?
15:20:14 q+
15:20:22 acolwell: that's not at the same time
15:20:35 pal: think there should be an OR in the spec - reader probably thinks it is an AND
15:21:01 ... if we think use case A is essential but the spec doesn't mandate the requirement for use case A then it isn't a quality of implementation issue
15:21:09 ack bob
15:21:20 BobLund: i agree with what pierre just said
15:21:34 q-
15:21:35 ... if this is a must to support then a requirement is there
15:21:50 Bob said what i was about to say
15:21:57 ack michae
15:22:05 ... what about non-normative text that lays out the use case and explains the need for support for more source buffers
15:22:13 paulc: have we strayed away from the original bug?
15:22:14 q+
15:22:29 ack ad
15:23:43 q+
15:24:06 Michael_Thornburgh: marking this won't fix should be contingent on another spec
15:24:16 ack Michael
15:24:30 paulc: would someone take an action to file an HTML5 bug proposing to solve in HTML 5.1 or a separate extension spec
15:25:02 paulc: do the editors know what kind of non-normative text would be required?
15:25:21 acolwell: no, this would be the first case of doing this - some example text would be useful
15:25:32 paulc: adrian, do you have an idea?
15:26:25 adrianba: happy to take an action to add some text - don't think it is needed but if it is needed to get consensus to resolve this bug then okay
15:26:42 paulc: does anyone want to volunteer to file the bug for the other use case
15:26:49 Michael_Thornburgh: i will file that bug
15:26:55 should I file a bug against Section 2.2 re: there should be an "OR"
15:27:04 ACTION: Michael_Thornburgh to file bug describing timed track changes
15:27:04 Error finding 'Michael_Thornburgh'. You can review and register nicknames at .
15:27:48 paulc: this will send mail to public-html-admin - you could send mail to public-html asking for people's opinions about if such a spec would be useful
15:27:52 q+
15:28:04 q+
15:28:19 adrianba: seems like it would be in scope for the media task force too
15:28:39 paulc: yes, but i think we want to get broad review
15:28:55 pal, sure - create the editorial bug - will deal as LC issue
15:29:19 ACTION: adrianba to propose non-normative text and resolve 22137
15:29:19 Created ACTION-28 - Propose non-normative text and resolve 22137 [on Adrian Bateman - due 2013-07-30].
15:29:29 q?
15:29:31 ack me
15:29:51 ack pal
15:29:58 pal: happy to create a bug for the OR issue
15:30:11 paulc: believe that resolves 22137
15:30:18 TOPIC: Bug 22136 - Inband Storage for SPS/PPS in ISO BMFF
15:30:26 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22136
15:30:29 ACTION-22?
15:30:29 ACTION-22 -- Adrian Bateman to work with jerry to confirm the proposal in 22136 is acceptable -- due 2013-07-02 -- OPEN
15:30:29 http://www.w3.org/html/wg/media/track/actions/22
15:31:07 jdsmith: i had asserted that the standard wasn't mature enough but we're withdrawing that
15:31:12 ... it is as mature as our spec
15:31:26 ... i propose a SHOULD and proposed text in the bug
15:31:27 Proposed text: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22136#c13
15:31:33 ... think aaron's proposal is pretty close
15:31:43 q+
15:32:35 stevep: could of things we notice - one is that switching from SPS/PPS it could be made more generic
15:32:45 ... HEVC allows other things in that configuration record
15:32:50 ... we'd like it to be a MUST
15:32:51 q+
15:32:58 ... for interop reasons
15:33:14 ... so that implementations can process any content
15:33:23 paulc: reason for MUST for the first and SHOULD for the second?
15:33:55 jdsmith: the first is an existing standard - we think the draft requires decoders to support this in multiple locations
15:34:18 paulc: usually discourage groups from arguing over MUST and SHOULD this early
15:34:33 ... one idea would be to make them both MUST and then mark at risk
15:34:39 q?
15:35:01 ack ac
15:35:24 acolwell: we should probably rework the text based on my recent fixes to the byte stream format so that it is in terms of what the user agent should do
15:35:50 ... sounds like this is about complying content so we need to rework into "the UA must do" style
15:35:57 paulc: which bug caused this?
15:36:00 acolwell: 22117
15:36:11 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22117
15:36:29 paulc: whatever text we have, this needs to be looked at in the context of that bug
15:36:31 ack ad
15:37:29 q+
15:37:45 adrianba: this whole section is optional in the spec - won't come into play for CR exit criteria
15:38:01 paulc: bbc is asking for a MUST and for the reference to be changed
15:38:04 ack pal
15:38:37 pal: section 12.2 is only for the implementations that choose to do so
15:38:47 ... if you choose to do this - SHOULD vs. MUST
15:38:53 q+
15:39:32 q+
15:39:33 q+
15:39:42 ack ad
15:39:50 adrianba: can live with it but don't think this will affect implementations
15:39:52 ac steve
15:40:05 stevep: our tests suggest this is easy to implement
15:40:15 ack aa
15:40:20 ac ste
15:40:21 ack ac
15:40:44 q+
15:40:57 acolwell: agree with adrian - can live with must but if we run across implementations that can't support with hardware then they won't do this - you can put a MUST but it doesn't mean all implementations will do it - we will be constrained by devices
15:41:04 ack steve
15:41:09 ack pal
15:41:32 q+
15:41:39 pal: to the original question - concerned that there are two implementers saying it cannot be implemented
15:41:42 ack ad
15:42:40 ... from a content creation standpoint - if it says MUST i can assume it is always there but it might not be there and that is something i should know
15:42:46 ... SHOULD means probably there but might not be
15:43:10 should
15:43:11 q+
15:43:14 paulc: is there anyone that can't live with it being a SHOULD?
15:43:18 steve
15:43:22 ack steve
15:43:37 stevep: our problem is that a SHOULD means that things that could implement it won't
15:43:53 ... we won't serve to devices that don't support it
15:43:58 q+
15:44:01 q+
15:44:06 acl ac
15:44:16 acolwell: don't think we can answer this question right now
15:44:24 waht about adding a note stating that DASH requires this feature?
15:44:43 ... as implementers have concerns that there would be devices we could support MSE on without this
15:44:53 ack pal
15:44:57 ... we should indicate that this might not be supported - could change to MUST later
15:44:58 ac ac
15:45:00 ack ac
15:45:15 pal: what about adding a note saying this feature is required in this other specification
15:45:34 acolwell: don't believe MSE says it must be able to support all of DASH
15:45:41 q+
15:45:56 ack ad
15:47:34 adrianba: proposal: make this a should with a note that describes that DASH content might not play back without this support
15:47:56 paulc: you'll get to see the text and can file a last call comment
15:49:04 paulc: proposal is editors 22136 resolved as fix with text that was proposed by jerry, amended with note that DASH content might not playback with this support, also amended with aaron's comment about in terms of UA
15:50:40 ACTION: acolwell to work with jerry to add text for 22136 into the spec
15:50:40 Created ACTION-29 - Work with jerry to add text for 22136 into the spec [on Aaron Colwell - due 2013-07-30].
15:50:55 TOPIC: MSE Last Call or heart beat Working Draft publication
15:51:12 paulc: chairs are trying to get heartbeat publications for all drafts
15:51:12 http://lists.w3.org/Archives/Public/www-archive/2013Jul/0040.html
15:51:35 ... leaving heartbeat to one side, we anticipated that at this stage we'd ask the task force and then the working group to go into last call
15:51:53