See also: IRC log
<paulc> paulc, who is here?
<scribe> Scribe: joesteele
paulc: any comments on the meetings? action items have ben carried forward
paulc: there are none for Media Source
paulc: three parts to Aarons update messages
... 13 bugs have been resolved by these updates
... let's not go through them all unless Aaron wants to highlight something or more discussion needed
acolwell: not anything in particular - mostly editorial or clarification
paulc: are all marked as fixed?
paulc: anyone want to comment/discuss more on these?
... moving on ..
paulc: 7 actions items -- let's check the status
... Define and document timestamps heuristics -- reply to MarkW response by the next meeting
paulc: ball is back in Aaron's court?
<paulc> Mark did his action. See https://www.w3.org/Bugs/Public/show_bug.cgi?id=18400#c5
paulc: next item - bug#17000
johnsimm: need more research - still pending
paulc: bug#17002 -- specificy source id to video track id mapping
... Aaron posted a message -- need followup?
acolwell: is this sufficient? if so then can update the spec
adrianba: did not get all the way through
... where does the original id come from? is there a way to create it?
<paulc> Aaron's update is at https://www.w3.org/Bugs/Public/show_bug.cgi?id=17002#c7
acolwell: no depends on the original expectation - no specific guidance given by the spec as long as unique
adrianba: my reading is could come from the source element
<paulc> See also Aaron's email to the list at http://lists.w3.org/Archives/Public/public-html-media/2012Aug/0008.html
adrianba: could come from the media file itself
... if it was coming from the media, reason to believe the application could know the mapping from the media
... if created programmatically, not clear how the mapping is established
<paulc> Possible bug on Media Fragments WG work: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17002#c5
acolwell: 2 issues -- correlation to a source buffer, correslation to a media segment
... issue with media segment, may have different track ids as could change during playback
... are we ok with the track id changing during playback? what should we do?
... current spec allows this to change
adrianba: are there two issues? which source buffer is related to a specific track and how to get there from a particular track
acolwell: would be good to separate out these
... now that object-oriented model exists
paulc: Silvia sent a comment to media wg -- is this another problem?
acolwell: there is a disconnect between media frag spec and the HTML5 spec in the language
... also text track does not have an ID attribute like video and audio tracks do
... there is no way to get an ID for a text track even with this change
paulc: this sounds like 2 sep bugs on the HTML5 spec
... Silvia may send this to the media frag WG
<scribe> ACTION: acolwell file a bug on HTML5 spec that text tracks should have an id like audio and video tracks do [recorded in http://www.w3.org/2012/08/28-html-media-minutes.html#action01]
acolwell: should a file a bug on how to handle?
<scribe> ACTION: acolwell file a bug to specify how the ID per track is generated with the Media Source Extensions [recorded in http://www.w3.org/2012/08/28-html-media-minutes.html#action02]
paulc: moving on
paulc: Aaron you had an actton on this
acolwell: did not do this yet
<paulc> We need someone with more DASH experience to take this on.
markw: I can take that ACTION 17006
paulc: next bug#17094
paulc: Bob Lund was the champion
BobLund: yes I have done that -- in the process of pulling together the proposed text. Should be ready in the next few days
... discuss in the next few weeks
paulc: please send email to the list
... next bug#16998
paulc: Aaron was going to split the bug
acolwell: have not done that yet -- but lots of other stuff handled!
paulc: moving to next agenda item
... 23 bugs outstanding
paulc: lots of bugs have come in from Opera
acolwell: yes -- bugs are high quality though
paulc: most of these bugs are clarifcations
acolwell: stuff is not specific enough or looks normative but is not
paulc: bug#180601 -- have we discussed?
Contradictory requirements for initialization segments
acolwell: spec is inconsistent about whether init segments are required
... lot of behavior is centered around this
... optional language makes this confusing
... should we still say they are optional?
... all current formats have init sgements
... this would be to support formats that come later which do not have them
paulc: can you give us a ptr to the most recent spec?
johnsim: is the issue that some media might not require init set?
acolwell: believe Mark wanted the optional text but cannot think of one today that has that
... Mark is copied on the bug
paulc: assign an action item to Mark on this
acolwell: Bob -- for Transport stream stuff you still have this right?
<matt> trackbot, status?
<scribe> ACTION: markw review the proposal in bug#18601 [recorded in http://www.w3.org/2012/08/28-html-media-minutes.html#action03]
<trackbot> Sorry, couldn't find user - markw
paulc: next item
acolwell: most of section 2 looks non-normative
... suggested to mark the whole section as non-normative
... I suggest changing to be normative instead
... should split bug into multiple sections to change to normative?
... or keep as a single bug?
paulc: there are 11 sub-sections
... what was original intent? descriptive text for reader and normative text for implementor?
... Aaron you are suggesting converting all the text to normative
paulc: would be better to move the normative stuff out of section 2?
acolwell: not sure
<markw> there is a lot of material in section 2 that should be normative
paulc: suggest you do one or two of these changes and come back to the group
adrianba: lot of things that are normative in this section - should get an idea of what to do as we change it
<markw> users of the API need to be sure how the different append cases will be handled, for example
paulc: maybe change a couple of good examples on section 2 and come back to group with the examples as a proposal
acolwell: some pieces are conceptual and some are more algorithmic - hard to see what is the right balance
paulc: no problem with having both types, but make sure it is clear which is which
<scribe> ACTION: acolwell to give a couple of examples for section 2 [recorded in http://www.w3.org/2012/08/28-html-media-minutes.html#action04]
<trackbot> Created ACTION-6 - Give a couple of examples for section 2 [on Aaron Colwell - due 2012-09-04].
paulc: moving on to next
acolwell: wanted people to look at this bug and get feedback
... on the behavior specified
... would like someone with more experience with this type of edge case to respond
paulc: anyone with this type of feedback?
acolwell: live is probably the problem
johnsim: Aaron if you could send me an email with a synopsis I can look for an answer
acolwell: Bob or Duncan could you chime in as well?
<Clarke> I'll take a look also
<duncanr> ok will look at it too
acolwell: this was in reference to transport streams
paulc: next item
acolwell: current spec says when you call end of stream can't add any more data
... might be nice to append after this if a higher quality segment has been found later
... this bug lifts the restriction, if you append transitions back to open state
... is this useful?
paulc: any comments?
... next is bug#18709
acolwell: adding a method to source buffer allowing you to flush data out of the source buffer
... one of the ideas was to allow app more control over how much data buffered in user agent
... also used to signal parts of timeline which are not important anymore
<paulc> See response in https://www.w3.org/Bugs/Public/show_bug.cgi?id=18709#c1
???1: what is the assumed behavior if it can act on its own?
acolwell: basically the user agent can do what it needs with regard to releasing memory but tries to avoid stopping playback
johnsim: allows app to give the UA a pass on playback for a piece of content
acolwell: allows UA to not have to guess
<markw> sometimes there are contractual restrictions on how much content can be buffered and this gives the application control of that
acolwell: agreed with the comments from Phillip
adrianba: think you said this allows app to be proscriptive, but earlier seemed like a hint and allowed the UA more information
<markw> I think it should be prescriptive
acolwell: it should be prescriptive
adrianba: is this intended to be synchronous then?
acolwell: intended to be like an overlap
paulc: think that handles Aarons suggested list
... some of the other bugs may be processed by him as well since they will be covered by his other work
acolwell: will keep attacking clarification bugs first and new features second
paulc: lots of actions
... meet again on Sept 11th in two weeks
... scribe volunteers?
... any other comments?
adrian will send matt the notes from this meeting
paulc: meeting is adjounred
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Mirc_Timestamped_Log_Format (score 0.89) Succeeded: s/priveuous/previous/ Succeeded: s/till pending/still pending/ Succeeded: s/lot's/lots/ Succeeded: s/mark:/markw:/ Succeeded: s/ar enot/are not/ Succeeded: s/pass playback/pass on playback/ Succeeded: s/???1/johnsim/ Found Scribe: joesteele Inferring ScribeNick: joesteele Default Present: NiXu, pierre, joesteele, Matt_Womer, PaulC, BobLund, acolwell, markw, Clarke, duncanr, ddorwin, Matt Present: NiXu pierre joesteele Matt_Womer PaulC BobLund acolwell markw Clarke duncanr ddorwin Matt adrianba paulc boblund Nixu kstreeter pal johnsim matt Agenda: http://lists.w3.org/Archives/Public/public-html-media/2012Aug/0049.html Got date from IRC log name: 28 Aug 2012 Guessing minutes URL: http://www.w3.org/2012/08/28-html-media-minutes.html People with action items: acolwell markw[End of scribe.perl diagnostic output]