See also: IRC log
<trackbot> Date: 15 January 2013
<scribe> ScribeNick: adrianba
<scribe> Scribe: Adrian Bateman
paulc: done
http://www.w3.org/2013/01/08-html-media-minutes.html
paulc: no comments
paulc: none for MSE
EME -> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
paulc: lower in the agenda you'll see candidate FPWD
MSE -> http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
paulc: last updated jan 4
paulc: CfC is here
http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0005.html
... closes tomorrow
... chairs have assigned me the task that if it passes we'll
move to the stage of trying to publish the document as
FPWD
... only thing we need to decide is short name
... we've proposed media-source
... it just needs to be unique
... we have to send a transition request to the chairs list and
the W3C Team on behalf of the Director responds
... one of the proforma things we have to do is give them the
short name
... as well as links to document, status, decision, etc.
... you should expect to see a note from me and the editors
will see a note suggesting to work with Mike Smith to get it
published
... next is the EME spec
... we discussed 4 items that needed addressing
... bug 17199 - proposal
http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0011.html
... has that been implemented?
markw: discussion with David and
proposed a different approach
... if we take this different approach outlined in David's mail
then it needs some different changes
paulc: just reviewing the thread - you add 20622
markw: i think this is a minor issue
paulc: what does the group want
to do - one of the items is not done
... candidate FPWD ->
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html
... do we want to wait, or push this aside
markw: if the group agrees with
the general approach then we could get the text worked out
today
... which could be the basis for the CfC
paulc: adrian mentioned it took a
lot longer to prepare for pubrules than expected
... hopefully none of that will be regressed
... so the proposal is to take the results of the thread and
add that to the candidate FPWD
ddorwin: the last mail about
null, etc. still needs some thinking about
... there may be other uses cases for null
... i attached a patch with async session id, etc
... there is already a key release section in the doc
... we don't expect that FPWD is completely implementable
... i don't see a problem with going with what we already
have
... if we don't decide on this call then when will we
decide
paulc: you outlined some additional problems and then questioned whether 17199 is a blocker
markw: on the technical issue on
the use of null - we don't say that is specifically retrieved
to key release
... null would retrieve any session that was stored for
whatever purpose
... i do think we should try to address this with the original
proposal or David's revised proposal
paulc: not sure what to do - perhaps we should go on and see if there are any other blockers
markw: can we fix this today and go for CfC tomorrow?
paulc: i'm okay with what you're
proposing if everyone else is clear and it's clear what the
mandate is
... little uncomfortable with two people are going to fix the
bug - would prefer will fix the bug in a specific way so that
CfC can say we will take the candidate FPWD plus this change
forward to the WG
<markw_> My proposal would be: (i) adopt David's proposed changes to createSession() ...
paulc: do you think you have enough confirmed? if not then probably means a week delay
<markw_> (ii) address asyncronous assignment of sessionId
<markw_> (iii) specify a way to retrieve persisted sessions
ddorwin: latest email is open
ended about persistent sessions - think it would be hard to be
specific
... don't think it's as simple as just adding some text
adrianba: think the goal of FPWD
is to set scope and the section is in the document
... we should move ahead with what we have and then fix the
bug
markw: i think what we said was
we wanted this in the FPWD
... i'd prefer this even if there is a one week delay
ddorwin: i think we have it covered as an issue, don't think anyone will implement as FPWD, new proposal is simpler and not a lot of algorithms needed
acolwell: seems to me that we don't have agreement so it sounds like we need another week - doesn't seem like we'll get to the decision - we should move on
paulc: next bug is 17682 - not clear what had happened
ACTION-9?
<trackbot> ACTION-9 -- John Simmons to discuss 17682 with markw and propose text for JSON solution -- due 2012-12-18 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/9
johnsim: this work was done
... i submitted the changes in the bug
... this was incorporated into the candidate FPWD
paulc: next is 18531 - believe
this is done
... next is 20335 - adrian was supposed to do this week
... bug is still open because as noted by david there is still
an open question about 2 states being enough
... don't propose we discuss now
... bulk is done
... so i believe we have a candidate working draft that covers
17682, 18531 and most of 20335
... we still have 17199 and the new bug 20622
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html
paulc: sounds like the best
consensus that causes least amount of dissent is to give TF one
more week to flatten the remaining bugs
... and get a new candidate FPWD by next week
... editors should expect a one week delay
ddorwin: what happens if we're not in agreement by next week on this issue?
paulc: in a consensus based
organisation like w3c it is hard to anticipate all
eventualities
... if you can't reach agreement then need to bring the
questions out onto the mailing list ASAP and people need to
propose alternate ways of solving
... maybe get an agreement on how to mark-up the document that
identify the areas of contention (we did this with MSE and
included pointers to bugs that people felt were
important)
... it's okay to publish FPWD with one or more health warnings
in it
markw: i think david's proposal
is a good one - i mentioned three items in IRC earlier
... you said first 2 were straightforward and last was more
controversial
... think those are the only things necessary
paulc: one possible solution is to get first 2 done and separate mail or bug on third item
<markw_> actually there is (iv) FAQ text, but I hope we can re-purpose text
paulc: could you live without part 3
markw: let's see if we get there
paulc: leave EME at this
point
... david and mark have the task to get us a revised
document
paulc: Aaron started two mail
threads with items to discuss
... Rethinking MediaSource.setTrackInfo() and
MediaSource.getSourceBuffer()
http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0007.html
acolwell: this is suggesting that
we replace these methods with modifying the underlying HTML
objects for the tracks to make it seem more natural
... propose to specify them in the media source draft
... after CfC I was contacted by a couple of people about how
they work
... wanted to propose that we rethink it
... to do something more natural not constrained by HTML spec
process
... are people okay with these changes
paulc: does this attach us more directly to the HTML spec?
acolwell: no, it takes the
existing HTML track objects and we're going to redefine two
attributes and add another
... if an implementation supports MSE then it adds these
changes on
... main change is kind and language are read-only in HTML spec
- here we make them writable
... we just have these in the MSE spec - if HTML.next decides
to make these writable in the future they can just use our
definitions
paulc: the last item you pointed out was if we publish a doc with these writable - maybe we file a HTML 5.1 bug to make them mutable since one extension works
acolwell: not sure if this will
always be a separate document
... filing the bug would make sense
paulc: any other questions?
bug 17002 and bug 17006
acolwell: should i change the fpwd?
paulc: no, i don't think so - let's work on getting a future draft out
adrianba: either reopen existing bugs or new bugs with a link to the old ones
paulc: my preference is to reopen
acolwell: do we have agreement that this is the right solution?
paulc: i haven't heard anyone
complain about this
... anyone have a problem with this?
... going to assume people are okay with this
+1
paulc: go ahead and get this into the editor's draft
acolwell: ok
paulc: next is Bug 18615 - HTMLMediaElement.buffered behavior in "ended" state
acolwell: this one is tricky and
not sure how to proceed - really looking for input at this
point
... variety of problems with appending sections and when you
call end of stream you might have segments with gaps
... as well as tracks with significantly different
lengths
... need to be some clarity about what to do - don't usually
get this situation with media in files
... right now the spec does this hand wavey thing where it only
considers the last buffered range
... and if playback is in last buffered range then will play
through to the longest
... but what happens if there is a gap and end of stream was
called
markw: just writing some answers and assumed end of stream was on sourcebuffer but it is on media source not on the buffer so you can specify they end at different times?
acolwell: assume end of stream is
a global state for playback
... so calling it is the signal that you're not going to append
any more data
markw: i think if the signal is
that the latest data is the final one in that track
... we allow out of order appends but end of stream could mean
this buffer gets no longer
... you could go back and fill in gaps
acolwell: but what is playback supposed to do with gaps?
markw: same as it always would - it would stall waiting for you to fill in the gap
acolwell: then i don't see the different between a global and per buffer end of stream
markw: the difference is the
global one means i have to append every last frame for every
buffer
... which means playback could get to the end of a buffer and
stall because you haven't said yet that it is the end
paulc: mark, did you send this in mail?
markw: not yet - half way through writing it
acolwell: please send to the list - need to think some more
paulc: any other bugs you wanted to pick up on?
acolwell: meant to send mail on
this other one:
... https://www.w3.org/Bugs/Public/show_bug.cgi?id=18592
... How much is "enough data to ensure uninterrupted
playback"
... main issue is event have enough data - concern by philip
that because there is no way for UA to know if it has enough
data to play through to the end
... he was suggesting that the readystate never transition to
enough data and always stay in future data
... this means autoplay will not work
... i want to know if the group accepts that
... i don't think it is acceptable because people will be
surprised by autoplay not working
... we need to reinterpret how to know if it can play through
to the end
... interested in other opinions
BobLund: to me it seems intuitive the other way - not having autoplay would be okay since script is necessary - doesn't seem like a stretch to say it script knows when to play
acolwell: for someone building a
player library on top of media - shouldn't need to know where
the data came from
... that's where i thought it might be surprising that it
doesn't work
BobLund: in that scenario it
seems like the functions doing the filling of the sourcebuffer
have the best information about when play can start
... so maybe the library determines when play begins
acolwell: ok
... the other reason to go between ENOUGH and FUTURE for the UA
to be able to signal when it needs more data
... if ENOUGH means the UA is happy with the data it has and if
the amount gets too low the UA could go to FUTURE and then the
app knows it isn't filling fast enough
... that does stray from HTML5 definitions though
paulc: anyone else?
... is that a conclusion?
acolwell: i could remove it - still want to know what others think
adrianba: i'd like more time to review with our team
paulc: given there has been no email discussion - think you should send out mail and we can pick this up either in mail or at the next meeting
acolwell: relatively small spec change but significant to web developers
paulc: okay, think we're done for
today
... most significant action is to get EME bug finished
... next week we'll start with EME FPWD discussion
... would be useful to queue up some other items for
discussion
acolwell: one other question - when CfC is done, what needs to be done on editor's side
paulc: you'll see private email
to editors copying Mike Smith
... basically Mike runs document through pubrules and
coordinate if there is extra work to be done
... could send mail right now - say it is in CfC
adrianba: i can cover this while you're away
paulc: adjourned
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 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: adrianba, paulc, pal, Aaron_Colwell, [Microsoft], +1.425.202.aaaa, ddorwin, johnsim, Mark_Watson, +1.303.661.aabb, BobLund Present: adrianba paulc pal Aaron_Colwell [Microsoft] +1.425.202.aaaa ddorwin johnsim Mark_Watson +1.303.661.aabb BobLund Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0016.html Found Date: 15 Jan 2013 Guessing minutes URL: http://www.w3.org/2013/01/15-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]