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

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

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?

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

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?

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