HTML Media Task Force Teleconference -- 23 Jul 2013

<trackbot> Date: 23 July 2013

<scribe> ScribeNick: adrianba

<scribe> Scribe: Adrian Bateman

Roll call, introductions and selection of scribe

paulc: done

<paulc> Agenda: 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> 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> 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> http://www.w3.org/html/wg/media/track/actions/21

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137#c8

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 http://www.w3.org/2013/07/23-html-media-minutes.html#action01]

<trackbot> Error finding 'Michael_Thornburgh'. You can review and register nicknames at <http://www.w3.org/html/wg/media/track/users>.

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 http://www.w3.org/2013/07/23-html-media-minutes.html#action02]

<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

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> 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: 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

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 http://www.w3.org/2013/07/23-html-media-minutes.html#action03]

<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

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

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

- DRAFT -

HTML Media Task Force Teleconference

23 Jul 2013

Attendees

Contents