See also: IRC log
<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
paulc: done
http://www.w3.org/2012/07/14-html-media-minutes.html
paulc: no actions for MSE
http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
paulc: Moved SourceBufferList.remove() to MediaSource.removeSourceBuffer()
<glenn> yes
paulc: this is bug 17082
... marked as RESOLVED FIXED
http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0062.html
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
http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0074.html
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
http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0035.html
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18389
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18400
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
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17739
scribe: any reason why this can't just be implemented
acolwell: yes, i can do this
paulc: editors will action
this
... bug 17002
https://www.w3.org/Bugs/Public/show_bug.cgi?id=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
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
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
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]