HTML Media Task Force Teleconference -- 17 Jul 2012

<trackbot> Date: 17 July 2012

<scribe> ScribeNick: adrianba

<scribe> Scribe: Adrian Bateman

<yang> I have muted me... any noise now?

Roll call, introductions, and selection of scribe

paulc: done

Previous meeting minutes

<paulc> http://www.w3.org/2012/06/19-html-media-minutes.html

paulc: there were a couple of items that we created semi-actions from the last minutes

Review action items

https://www.w3.org/html/wg/media/track/

paulc: none for MSE

Baseline documents

Editor's Draft: http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html

Media Source Extensions bugs: http://tinyurl.com/6pdnzej

Spec updated to object-oriented API

http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0005.html

acolwell: basically, i made all the changes we discussed before and rewritten most of the text
... mainly it was moving methods around and putting them in objects as discussed
... i did not include the append URL part - i felt we were still discussing this
... i also tried to address a couple of other bugs
... for example about audio tracks and video tracks
... and added appropriate language about text tracks
... don't think this is completely done but better
... added extra property called activeSourceBuffers
... the buffers associated with selected tracks (currently selected video and all selected audio tracks)
... but it was hard to tell which buffers were involved
... this is the set of buffers that you need to continue appending to to allow playback to continue

paulc: anyone with questions?

yang: where was the spec modified for text tracks?

<paulc> >- Added TextTrack language in various places since it was overlooked in the

<yang> added appropriate language about text tracks

yang: html5 spec already has language information

acolwell: i added text to the document that is related to text tracks
... it's not that I added a language attribute
... i added text to describe how text tracks are handled because it was missing before

yang: got it, thank you

<acolwell> http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#track-buffer

acolwell: here is an example where i mention text tracks

<paulc> >http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0020.html

<acolwell> http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#sourcebufferlist

acolwell: this is the existing sourcebufferlist IDL

<acolwell> http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#mediasource

acolwell: this is the existing mediasource IDL
... the idea is to move the remove() method from sourcebufferlist to mediasource as removeSourceBuffer()
... there are couple of reasons for this
... one argument is consistency - always add and remove from the same object - the mediasource
... it would be nice for this to be symmetrical
... now there there is a sourcebuffers and activesourcebuffers - if i remove a buffer from one of these then it should affect the other
... if i remove a buffer that is part of activesourcebuffers, currently i could say activesourcebuffers.remove()

and this would also remove from sourcebuffers (because activesourcebuffers is a subset of the other)

scribe: and it would be surprising to people if this affected both
... from an implementation perspective it is tricky to coordinate the two lists so events fire at appropriate times

yang: there is no activesourcebuffers attribute?

acolwell: yes, it's the second from the top

yang: the remaining buffers will be inactive?

acolwell: currently there is sourcebuffers with all buffers and activesourcebuffers which is just the ones backing the active tracks (the current video track, selected audio tracks, and appropriate text tracks)

yang: how do you make a source buffer active?

acolwell: they become active based on the mechanism for selecting and enabling tracks in the HTMLMediaElement
... videotracks has a selected attributed and each track in audiotracks has an enabled property
... whenever the underlying track becomes active the associated buffer will move into the active list

yang: remove is available to the activesourcebuffers - is it available to sourcebuffers also?

<yang> remove is availabe to sourcebuffer list?

acolwell: my proposal is to make remove only part of mediasource because it is really about removing the buffer from the source completely and not from a particular list
... moving this into the mediasource object we can remove from both lists with the single call if necessary

paulc: it is one thing to have a side-effect to have the buffer added to the active list but it would be strange to have it work in reverse

acolwell: if you remove a sourcebuffer from the activesourcebuffers it will affect the currently selected video track - there is some text that talks about what should happen in this situation
... my point is that instead of removing from one list you remove from the source then it makes more sense that it is removed from both lists

<paulc> This discussion is about https://www.w3.org/Bugs/Public/show_bug.cgi?id=17082

paulc: the current draft includes everything except the discussion in msg 20

acolwell: are people comfortable with just making this change or should we share text on the list?

yang: if we move remove from sourcebufferlist to mediasource then there will be an extra method on mediasource

<yang> remove method should be in parent node of sourcebufferlist

acolwell: i don't understand the objection - having remove on sourcebufferlist is not simpler because the two lists need to be synchronised
... putting it in sourcebufferlist implies the two lists are independent and they are not

<yang> they are not indepent?

<acolwell> no. activeSourceBuffers is a subset of sourceBuffers

<yang> ok

<yang> got it

<yang> no objection now.

acolwell: all of the objects in activesourcebuffers are in sourcebuffers

paulc: is the right way to proceed to propose text in an email?

adrianba: i propose we just update the document

<glenn> agreed

paulc: anyone object to updating the document?
... no objections

yang: there will be a bug or email?

paulc: there already is an email - msg 20

<glenn> yang, you can review the change after it is in the document

<yang> but i can not find which part change,in fact some part i have not reviewed

paulc: aaron, could you open a bug or send mail and make link to the check-in

acolwell: i should be able to make the change for remove() today and then let the group know by email where the change is

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

paulc: do these changes resolve this bug?

acolwell: yes

paulc: please mark the bug as fixed with links to email archive

acolwell: okay

Candidate Media Source Extension bugs for discussion

http://tinyurl.com/6pdnzej

paulc: could we look at bug 16997

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16997

paulc: Redesign mediaSourceURL mechanism to allow declarative syntax
... does the object orientation change affect this?

acolwell: now that we're using createObjectURL there is no way to have a declarative method so this is out of scope

paulc: when the editor's mark 17082 as fixed, mark 16997 to make this out of scope

acolwell: okay

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16998

paulc: we discussed this at a previous meeting
... earlier aaron you alluded that you didn't make this change
... but i think we gave you an action on june 19 to make this change

acolwell: i can start making these changes - i think i should update the proposal to match the O-O changes
... and propose new IDL so people can see what i'm talking about

<paulc> Previous Jun 19 discussion: http://www.w3.org/2012/06/19-html-media-minutes.html#item06

acolwell: and then there is a long email discussion about it

paulc: at the end of the discussion we said add new method and mark old one as at risk
... you haven't done this yet because you were focusing on the main O-O bug?

acolwell: correct

paulc: has there been continuing discussion invalidating the june 19 discussion?

acolwell: i think i want to summarise what we agreed on to see if people still agree

yang: bug 16998 - the proposed change for source URL is start/length but originally it was start/end
... if i use length then i might forget where to start next time but if i use end then it will be easier
... do you still think start/length will be simpler?

acolwell: i think it will be less error prone because start/end follows HTTP range and for one byte the start and end are the same
... but for length you can add length to the start to find the next start

yang: you think this is simpler?

acolwell: yes, start/length is more intuitive

<paulc> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=16998#c6

markw: we need to figure out how to provide the application with progress of bytes arriving like XHR
... i need to know this for each appendURL call
... we don't quite have the structure there yet
... we could do this with progress events on the sourcebuffer or we could create something like XHR or something else

paulc: you're okay with providing a summary and proposal on 16998?

acolwell: yes
... i agree with mark to about progress events
... for example, should we take a step back and figure out integration with XHR?

paulc: please provide a summary email about where we have agreement and where there are other hard questions remaining
... if you can enumerate these as questions then we can get people on the list to offer answers or review your proposals
... next item from the last meeting https://www.w3.org/Bugs/Public/show_bug.cgi?id=17004
... last meeting discussion was inconclusive
... discussion ended with "continue discussion on email"
... have we made enough progress on this?
... this appears to have split into a thread about ad insertion

<paulc> Ad insertion: http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0033.html

paulc: and another thread where aaron provided a summary of where we are

<paulc> Summary on 17004 thread: http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0035.html

paulc: i'm wondering how we process this bug? what do we do about the split - is this more than one bug?
... there has been some further discussion
... it looks like this needs to continue on email?

acolwell: yes, i think we still need some discussion on timestamp offset - i thought of some new things to talk about over the weekend

<paulc> Thread discussion ends at http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0055.html

acolwell: perhaps we can come back to this at the next meeting and have enough progress to update the spec
... on ad insertion, i think that is a separate feature request
... i think it would be interesting to have this discussion but it isn't directly tied to the MSE work
... and if the media list is the appropriate place to discuss this

paulc: you're saying this isn't a bug against the 2 specs we have?

acolwell: it is about a time accurate pause and events
... it seems like more of a feature for the media element
... rather than MSE or EME

duncanr: i was initially confused about why we're adding the complexity for the timestamp mechanism
... and i'm curious to know how to progress any switching mechanism in the thread
... but there may be need for additional standardisation and the question is where to put that

paulc: i think the right think to do is open a HTML5 bug on the media element with the requirements and use cases and point to this discussion to comment that this isn't covered by the media specs
... i would do this directly on the HTML5 component
... we'll treat the ad insertion thread as dealt with for now by duncan raising this as a HTML5 item
... we'll allow the mailing list discussion to continue

<paulc> http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0044.html

paulc: the next topic is msg 44
... Establishing the Presentation Start Timestamp
... for this item, does this need to be opened as a bug?

acolwell: it will likely require a spec update so should probably file a bug but wanted to start a discussion to see how people think we should handle this scenario

<paulc> Thread extends to http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0053.html currently

acolwell: the current spec doesn't really handle this and we've run into problems while trying to implement
... so i think we need more information about how presentation time is established

paulc: please can you file a bug?

acolwell: yes, and i'll respond to the thread

paulc: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17071

acolwell: i started a discussion on this

<paulc> See http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0050.html

paulc: "Define how presentation duration is set & updated"
... i'm assuming we want to continue the email discussion?

acolwell: yes, i don't think it will be too contentious

paulc: the only other thing i'd like to suggest
... between now and the next meeting, could the editors go through them
... we said we'd deal with O-O and then cover the other bugs
... could the editors propose specific changes for some of the bugs
... now that we've got the main O-O bug out of the way we need to make progress on multiple different fronts

Other business

paulc: next meeting in 2 weeks
... there is a period later in august - august 20th when i am travelling and may need to find another person to chair
... if anyone wants to help with volunteering to chair i will listen to offers

Adjournment

paulc: we're done - thanks aaron for all the work

- DRAFT -

HTML Media Task Force Teleconference

17 Jul 2012

Attendees

Contents