- From: Adrian Bateman <adrianba@microsoft.com>
- Date: Tue, 23 Jul 2013 16:24:49 +0000
- To: Paul Cotton <Paul.Cotton@microsoft.com>, "public-html-media@w3.org" <public-html-media@w3.org>
- CC: "Aaron Colwell <acolwell@google.com> (acolwell@google.com)" <acolwell@google.com>, Mark Watson <watsonm@netflix.com>
Minutes -> http://www.w3.org/2013/07/23-html-media-minutes.html [1]W3C [1] http://www.w3.org/ - DRAFT - HTML Media Task Force Teleconference 23 Jul 2013 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-html-media/2013Jul/0013.html See also: [3]IRC log [3] http://www.w3.org/2013/07/23-html-media-irc Attendees Present pladd, glenn, +1.831.457.aaaa, Michael_Thornburgh, +1.650.458.aabb, ReimundoGarcia, +44.173.776.aacc, paulc, Aaron_Colwell, [Microsoft], adrianba, pal, stevep, +1.303.661.aadd, BobLund Regrets Chair Paul Cotton Scribe Adrian Bateman Contents * [4]Topics 1. [5]Roll call, introductions and selection of scribe 2. [6]Previous meeting minutes 3. [7]Review of action items and issues 4. [8]Media Source Extensions editor's draft 5. [9]Pre-Last Call bugs 6. [10]Bug 22137 - changes in number of audio tracks during advert insertion 7. [11]Bug 22136 - Inband Storage for SPS/PPS in ISO BMFF 8. [12]MSE Last Call or heart beat Working Draft publication 9. [13]Candidate Last Call bugs 10. [14]Any other business 11. [15]Adjournment * [16]Summary of Action Items __________________________________________________________ <trackbot> Date: 23 July 2013 <scribe> ScribeNick: adrianba <scribe> Scribe: Adrian Bateman Roll call, introductions and selection of scribe paulc: done <paulc> Agenda: [17]http://lists.w3.org/Archives/Public/public-html-media/2013J ul/0013.html [17] http://lists.w3.org/Archives/Public/public-html-media/2013Jul/0013.html Previous meeting minutes paulc: don't think they need any discussion - used to drive the agenda Review of action items and issues paulc: all in the agenda Media Source Extensions editor's draft <paulc> [18]https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source /media-source.html [18] https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html paulc: updated once by aaron on july 18 - sent a note about changes Pre-Last Call bugs <paulc> [19]http://tinyurl.com/6pdnzej [19] http://tinyurl.com/6pdnzej 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 Bug 22137 - changes in number of audio tracks during advert insertion ACTION-21? <trackbot> ACTION-21 -- Adrian Bateman to work with Jerry to review bug 22137 and provide feedback -- due 2013-07-02 -- CLOSED <trackbot> [20]http://www.w3.org/html/wg/media/track/actions/21 [20] http://www.w3.org/html/wg/media/track/actions/21 <paulc> [21]https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137#c8 [21] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137#c8 [22]https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137 [22] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137 paulc: comments suggest won't fixing? acolwell: yes, i'm proposing that we create a different spec to handle track switching independently ... so that other html5 media can take advantage of it ... the comments after comment 8 talk about what situations could arise ... my position is that i agree there could be problems but we should make this another spec because it is an independent issue ... agree with adrian's earlier comment suggesting marking as Won't Fix <Michael_Thornburgh> i'm on the phone too paulc: one of the correspondents is Michael_Thornburgh ... do you want to make comments? Michael_Thornburgh: my concerns is mostly making sure the use case is addressed ... if the solution is another spec to make it possible that's okay ... i'm particularly concerned that the stalling behaviour is part of the MSE spec ... and you want to avoid stalls at append time ... 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 acolwell: my intention was that MSE talks about what tracks are taking into account during playback ... so stalls only happen if tracks playing don't have content ... this other proposed mechanism would specify when the switch happens ... and track switch would happen as if they were being done instantly ... but because you provide the data ahead of time, the media engine knows a switch is coming up ... however that spec addresses switching then it will allow for a window around the switch where it doesn't have to match exactly Michael_Thornburgh: that sounds reasonable <pal> is this great information provided by Aaron captured somewhere in the specification? acolwell: to pal's question, how stalls happened and what happens when a track is enabled or disabled is in the spec ... so this new spec would specify a track switch in terms of how tracks currently are enabled or disabled ... so MSE would work with that ... tracks enabled get added to active source buffers and affect stalling <Michael_Thornburgh> +q acolwell: when removed gets removed from active source buffers and doesn't have to have data for playback Michael_Thornburgh: the other issue is having more than two sourcebuffers ... probably ought to be some indication in the spec that sourcebuffers > 2 should be supported acolwell: i have concerns about mandating that adrianba: IE11 supports more than two sourcebuffers acolwell: i have concerns about specifying how many need to be supported - this is a quality of implementation issue ... don't need to put this in the spec pal: section 2.2 requires 3 source buffers, right? acolwell: that's not at the same time pal: think there should be an OR in the spec - reader probably thinks it is an AND ... 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 BobLund: i agree with what pierre just said ... if this is a must to support then a requirement is there <Michael_Thornburgh> Bob said what i was about to say BobLund: what about non-normative text that lays out the use case and explains the need for support for more source buffers paulc: have we strayed away from the original bug? Michael_Thornburgh: marking this won't fix should be contingent on another spec paulc: would someone take an action to file an HTML5 bug proposing to solve in HTML 5.1 or a separate extension spec ... do the editors know what kind of non-normative text would be required? acolwell: no, this would be the first case of doing this - some example text would be useful paulc: adrian, do you have an idea? 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 paulc: does anyone want to volunteer to file the bug for the other use case Michael_Thornburgh: i will file that bug <pal> should I file a bug against Section 2.2 re: there should be an "OR" <scribe> ACTION: Michael_Thornburgh to file bug describing timed track changes [recorded in [23]http://www.w3.org/2013/07/23-html-media-minutes.html#action 01] <trackbot> Error finding 'Michael_Thornburgh'. You can review and register nicknames at <[24]http://www.w3.org/html/wg/media/track/users>. [24] http://www.w3.org/html/wg/media/track/users%3E. 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 adrianba: seems like it would be in scope for the media task force too paulc: yes, but i think we want to get broad review pal, sure - create the editorial bug - will deal as LC issue <scribe> ACTION: adrianba to propose non-normative text and resolve 22137 [recorded in [25]http://www.w3.org/2013/07/23-html-media-minutes.html#action 02] <trackbot> Created ACTION-28 - Propose non-normative text and resolve 22137 [on Adrian Bateman - due 2013-07-30]. pal: happy to create a bug for the OR issue paulc: believe that resolves 22137 Bug 22136 - Inband Storage for SPS/PPS in ISO BMFF [26]https://www.w3.org/Bugs/Public/show_bug.cgi?id=22136 [26] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22136 ACTION-22? <trackbot> ACTION-22 -- Adrian Bateman to work with jerry to confirm the proposal in 22136 is acceptable -- due 2013-07-02 -- OPEN <trackbot> [27]http://www.w3.org/html/wg/media/track/actions/22 [27] http://www.w3.org/html/wg/media/track/actions/22 jdsmith: i had asserted that the standard wasn't mature enough but we're withdrawing that ... it is as mature as our spec ... i propose a SHOULD and proposed text in the bug <paulc> Proposed text: [28]https://www.w3.org/Bugs/Public/show_bug.cgi?id=22136#c13 [28] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22136#c13 jdsmith: think aaron's proposal is pretty close stevep: could of things we notice - one is that switching from SPS/PPS it could be made more generic ... HEVC allows other things in that configuration record ... we'd like it to be a MUST ... for interop reasons ... so that implementations can process any content paulc: reason for MUST for the first and SHOULD for the second? jdsmith: the first is an existing standard - we think the draft requires decoders to support this in multiple locations paulc: usually discourage groups from arguing over MUST and SHOULD this early ... one idea would be to make them both MUST and then mark at risk 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 ... sounds like this is about complying content so we need to rework into "the UA must do" style paulc: which bug caused this? acolwell: 22117 [29]https://www.w3.org/Bugs/Public/show_bug.cgi?id=22117 [29] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22117 paulc: whatever text we have, this needs to be looked at in the context of that bug adrianba: this whole section is optional in the spec - won't come into play for CR exit criteria paulc: bbc is asking for a MUST and for the reference to be changed pal: section 12.2 is only for the implementations that choose to do so ... if you choose to do this - SHOULD vs. MUST adrianba: can live with it but don't think this will affect implementations stevep: our tests suggest this is easy to implement 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 pal: to the original question - concerned that there are two implementers saying it cannot be implemented ... 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 ... SHOULD means probably there but might not be <ReimundoGarcia> should paulc: is there anyone that can't live with it being a SHOULD? <paulc> steve stevep: our problem is that a SHOULD means that things that could implement it won't ... we won't serve to devices that don't support it acolwell: don't think we can answer this question right now <pal> waht about adding a note stating that DASH requires this feature? acolwell: as implementers have concerns that there would be devices we could support MSE on without this ... we should indicate that this might not be supported - could change to MUST later pal: what about adding a note saying this feature is required in this other specification acolwell: don't believe MSE says it must be able to support all of DASH adrianba: proposal: make this a should with a note that describes that DASH content might not play back without this support paulc: you'll get to see the text and can file a last call comment ... 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 <scribe> ACTION: acolwell to work with jerry to add text for 22136 into the spec [recorded in [30]http://www.w3.org/2013/07/23-html-media-minutes.html#action 03] <trackbot> Created ACTION-29 - Work with jerry to add text for 22136 into the spec [on Aaron Colwell - due 2013-07-30]. MSE Last Call or heart beat Working Draft publication paulc: chairs are trying to get heartbeat publications for all drafts [31]http://lists.w3.org/Archives/Public/www-archive/2013Jul/004 0.html [31] http://lists.w3.org/Archives/Public/www-archive/2013Jul/0040.html scribe: 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 ... we need to ask the editors to create an last call draft at a unique URL ... then ask the task force for approval to forward to WG for a CfC ... how long will it take the editor's to produce the last call? acolwell: won't take long once we have the two edits done ... an hour or less after that we have the doc paulc: we can get approval from TF either through email or do it in two weeks at the meeting ... recommend that the TF permits me to do whichever occurs earlier ... if editors get draft done this week - run a CfC by email so we get done as early as possible ... otherwise we can do it at the next meeting ... so worst case approve no later than 2 weeks from now acolwell: works for me +1 paulc: antipating editors will close out these two bugs and announce they are done - if they supply me with a candidate LC doc i will start CfC in TF ... after that closes will discuss with co-chairs ... and make sure happens at WG level ... clear? Candidate Last Call bugs paulc: 22432 and 22371 ... both dealt with at jul 2 meeting ... proposed no change to 22432 - not implemented ... 22371, aaron was going to respond to the bug acolwell: haven't done yet - need to respond in the bug proposing it be created in a new doc paulc: like to suggest that editors go back and look at previous minutes and update bugs to say what our position is ... if someone objects to LC because of these bugs i would overrule because they came in after pre-LC but i think it is good practice to add current status in the bug Any other business <pal> have a nice day paulc: very close to last call ... will tell my co-chairs that we're planning to go to LC and won't need heartbeat Adjournment paulc: we're done Summary of Action Items [NEW] ACTION: acolwell to work with jerry to add text for 22136 into the spec [recorded in [32]http://www.w3.org/2013/07/23-html-media-minutes.html#action 03] [NEW] ACTION: adrianba to propose non-normative text and resolve 22137 [recorded in [33]http://www.w3.org/2013/07/23-html-media-minutes.html#action 02] [NEW] ACTION: Michael_Thornburgh to file bug describing timed track changes [recorded in [34]http://www.w3.org/2013/07/23-html-media-minutes.html#action 01] [End of minutes] __________________ From: Paul Cotton Sent: Monday, July 22, 2013 6:06 PM To: public-html-media@w3.org Cc: Aaron Colwell <acolwell@google.com> (acolwell@google.com); Adrian Bateman; Mark Watson Subject: {agenda} HTML WG media telecon 2013-07-23 - MSE status and bug discussion The HTML WG media teleconference meeting will occur on 2013-07-23 for up to 60 minutes from 15:00Z to 16:00Z. http://timeanddate.com/s/2e54 Tokyo midnight, Amsterdam/Oslo 17:00, London/Dublin 16:00, New Jersey/York 11:00, Kansas City 10:00, Seattle/San Francisco 08:00. Chair of the meeting: Paul Cotton Scribe: TBD (See the end of this email for dial-in and IRC info.) == Agenda == 1. Roll call, introductions and selection of scribe 2. Previous meeting minutes http://www.w3.org/2013/07/09-html-media-minutes.html 3. Review of action items and issues https://www.w3.org/html/wg/media/track/ MSE-related actions are given below. 4. MSE status and bugs a) Media Source Extensions editor's draft: http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html Status as of Jul 22: Last updated on Jul 18. b) Media Source Extensions bugs: http://tinyurl.com/6pdnzej Status as of Jul 22: 4 bugs. See list at end of this agenda. 5. Pre-Last Call bugs a) Bug 22137 - changes in number of audio tracks during advert insertion https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137 ACTION-21: Work with Jerry to review bug 22137 and provide feedback https://www.w3.org/html/wg/media/track/actions/21 Status: Closed. See Aarron’s response and subsequent responses: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137#c8 b) Bug 22136 - Inband Storage for SPS/PPS in ISO BMFF https://www.w3.org/Bugs/Public/show_bug.cgi?id=22136 ACTION-22: Work with jerry to confirm the proposal in 22136 is acceptable https://www.w3.org/html/wg/media/track/actions/22 6. MSE Last Call or heart beat Working Draft publication http://lists.w3.org/Archives/Public/www-archive/2013Jul/0040.html 7. Candidate Last Call bugs a) Bug 22432 - Allow SourceBuffer.appendBuffer to take ownership of the ArrayBuffer https://www.w3.org/Bugs/Public/show_bug.cgi?id=22432 Status: Candidate Last Call bug. Jul 2 meeting proposed no change to spec but not yet implemented. b) Bug 22371 - [MSE] Ogg byte streams https://www.w3.org/Bugs/Public/show_bug.cgi?id=22371 Status: Candidate Last Call bug. Aaron offered to respond at the Jul 2 meeting. 8. Any other business 9. Chair and Scribe for next meeting 10. Adjournment == Dial-in and IRC Details == Zakim teleconference bridge: +1.617.761.6200, conference 63342 ("media") https://www.w3.org/Guide/1998/08/teleconference-calendar#s_5366 Supplementary IRC chat (logged): #html-media on irc.w3.org port 6665 or port 80 Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (425) 705-9596 Fax: (425) 936-7329 ID▼ Assignee Status Summary Changed 22432 adrianba@microsoft.com NEW Allow SourceBuffer.appendBuffer to take ownership of the ArrayBuffer 2013-06-24 22371 acolwell@google.com ASSI [MSE] Ogg byte streams 2013-06-25 22137 adrianba@microsoft.com NEW changes in number of audio tracks during advert insertion 2013-06-17 22136 acolwell@google.com ASSI Inband Storage for SPS/PPS in ISO BMFF 2013-06-11 4 bugs found.
Received on Tuesday, 23 July 2013 16:26:53 UTC