HTML Media Task Force Teleconference

31 Jul 2012


See also: IRC log


+1.352.870.aaaa, +1.206.218.aabb, Clarke, adrianba, paulc, NiXu, acolwell, glenn, markw, BobLund
Paul Cotton
Adrian Bateman


<trackbot> Date: 31 July 2012

<NiXu> 352 is me

<scribe> ScribeNick: adrianba

<scribe> Scribe: Adrian Bateman

<scribe> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0094.html

Roll call, introductions and selection of scribe

paulc: done

Previous meeting minutes


Review of action items

paulc: no actions for MSE

Baseline documents and Bugzilla information



Actions from the previous meeting

paulc: Moved SourceBufferList.remove() to MediaSource.removeSourceBuffer()

<glenn> yes

paulc: this is bug 17082
... marked as RESOLVED FIXED


paulc: wanted to make sure everyone knew this was done
... next item is Redesign mediaSourceURL mechanism to allow declarative syntax
... bug 16997
... marked as RESOLVED WONTFIX
... those are the two items we pushed out of the way in the last meeting
... next is Change sourceAppend() to take a URL and optional range parameters
... bug 16998


paulc: i marked this in the agenda as needs more discussion - can we get an update?

acolwell: i summarised the old thread and tried to include the different perspectives
... and suggested we should take a step back and reevaluate what we're doing
... a lot of this looks like XHR
... so maybe we could use that instead of building this into MSE
... mark responded which i haven't had time to reply
... seemed to agree but nobody else has so i don't know if we have agreement

paulc: one other response

acolwell: yes, i need to review this

paulc: are your questions trying to break bug 16998 into separate bugs or just enumerate the hard questions to resolve the bug

acolwell: i think part is to split the bug into 2 pieces
... one requirement is about rate limiting appends
... and then there's the i want to append with either a URL or a blob
... one is a way for the UA to control how quickly the app can append things and the other about whether you avoid the data coming into JavaScript
... so i think there are two issues that i was trying to solve in one go but maybe should be separate
... i was hoping to get some feedback from people on the appending about which feels more natural

adrianba: haven't looked in detail yet - happy to take the action to provide Microsoft's feedback by the next call

paulc: i think you mean replying to aaron's original mail and at least determine if we can resolve by splitting as he proposed
... is there anything else we can do now?

acolwell: no

paulc: i'll carry this item forward and we can decide in two weeks if and how to split the bug
... Define a timestamp offset mechanism
... bug 17004


paulc: this was summarised earlier and then a few replies

acolwell: the discussion continued and then yesterday i published spec updates that include this
... was going down the path of having a stack and then proposed that we could have that in JS alone
... and went back to the simple mechanism
... and there were no objections after a short discussion

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

acolwell: so i updated the spec

paulc: that includes 17004 and some other changes?

acolwell: yes - not mentioned in the agenda
... also has the duration changes that were discussed

paulc: bug 17004 is now marked RESOLVED FIXED

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

paulc: bug 17071 also RESOLVED FIXED
... Define how presentation duration is set & updated
... there are new bugs related to timestamps
... Remove format specific presentation start timestamp sections


paulc: are you just looking for comments?

acolwell: there was a discussion about removing a mechanism for determining start time
... it currently uses timestamp of initial segment
... and as we implemented we ran into some problems
... so we proposed always starting at zero
... and use the timestamp offset mechanism if your media doesn't do this
... i think mark and i agreed but then there was some side discussion
... in the last spec update i added text to describe the existing behaviour so people could look at it
... but if we decide presentations should always start at zero then we can remove that

paulc: the bug has a very concrete proposal - maybe we give people one week to respond - is that enough time?
... alternatively you could just make the change and if necessary back it out
... someone had some questions and i think i answered but i didn't get an idea of whether the answers satisfied him
... my recommendation is review as you suggested and then make the change as a single check-in
... mark the bug when you do it and then we can review

adrianba: +1

paulc: next is Define and document timestamp heuristics


paulc: this one asks lots of questions
... assigned to mark

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

markw: i asked for this to be assigned to me but haven't done it yet - will address by the next call

paulc: this will be on the agenda for the next meeting

Candidate Media Source Extension bugs for discussion


paulc: not sure how to handle these
... when we originally met, we said we'd wait on many of these for the API changes

acolwell: 17001 - not sure how to deal with this
... i've added text but this was mainly due to Bob Lund pointing out that this was discussed
... not sure how to proceed

paulc: suggest you go back to the bug with a pointer into the spec saying where the changes are
... and then you compose a mail to Bob copying the list asking if this resolves the issue
... we should do this for all bugs we believe resolved
... give a two week window and then treat as closed
... does that apply to any others?

acolwell: bug 17000 - i lowered the priority because i don't think we know how we move forward on this
... i don't think we have any capabilities that need negotiation
... so i don't know whether to close this bug until we need it or leave it open

paulc: adrianba?

adrianba: i need to get john simmons to look at this

paulc: adrian or john will provide microsoft's opinion on this

acolwell: i think kilroy was the one with thoughts on this

adrianba: ok

paulc: what about bug 17739


scribe: any reason why this can't just be implemented

acolwell: yes, i can do this

paulc: editors will action this
... bug 17002


acolwell: we don't have source IDs any more because of going to the O-O API
... so now we just have source buffers

paulc: i suggest closing the bug and pointing to the new open bug

adrianba: i think it makes more sense to retitle the bug since the problem is still the same

paulc: that's fine as long as it is clearly commented in the bug

acolwell: i'll go back and look at the history

paulc: bug 17006
... <track> Setting track language & kind when the information is in a manifest

acolwell: i need to rethink this - i'll take an action to look again given the new API

paulc: bug 17072
... Define behavior for a break in contiguous appending

acolwell: i think we may have had discussions that make this no longer relevant
... i will look and update

paulc: bug 17094
... Define segment formats for MPEG2-TS
... could someone take a look and recommend how to deal with this

acolwell: this one may be controversial

paulc: perhaps someone could create a summary and we can discuss in the next meeting?
... i think that's all of them
... i will make sure i use the minutes to drive the next agenda

Other Business

adrianba: just wanted to ask how close we think we are to feature complete
... once we get there we could consider asking the WG for FPWD

paulc: when this was presented you gathered all the comments from the list and turned into bugs?

adrianba: yes

paulc: there are a couple of important bugs still to be worked on
... maybe we should put a call out asking for items that are missing from the spec

acolwell: i think the append mechanism and the rate limiting are key things

paulc: are they included in bugs?

acolwell: yes

paulc: paraphrasing adrian's question as if we close the current bugs is that good enough to go to FPWD
... then we can consider if there are some that don't even need to be resolved to get there

acolwell: i think we're close

<glenn> yes, go to FPWD

paulc: another question: i don't think there's a reason we couldn't publish this spec as FPWD without the EME spec - they are independent, correct?

acolwell: yes

adrianba: yes

paulc: i will send a note to the media list saying that we've done the major change to the API, we're moving along, and we're looking for any missing functionality
... does that answer your AOB question?

adrianba: yes

Chair and Scribe for next meeting

paulc: next meeting will be aug 14
... i will chair
... any volunteers to scribe?
... not hearing anyone


paulc: all done for today, lots of work to be done though
... we're adjourned

trackbot, end telcon

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/07/31 15:49:38 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: adrianba
Found Scribe: Adrian Bateman
Default Present: +1.352.870.aaaa, +1.206.218.aabb, Clarke, adrianba, paulc, NiXu, acolwell, glenn, markw, BobLund
Present: +1.352.870.aaaa +1.206.218.aabb Clarke adrianba paulc NiXu acolwell glenn markw BobLund
Agenda: http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0094.html
Found Date: 31 Jul 2012
Guessing minutes URL: http://www.w3.org/2012/07/31-html-media-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]