RE: {minutes} HTML WG media telecon 2013-01-15 - MSE and EME FPWDs, MSE bug status

Minutes -> http://www.w3.org/2013/01/15-html-media-minutes.html


- DRAFT -

HTML Media Task Force Teleconference

15 Jan 2013

 Agenda

See also: IRC log

Attendees

Presentadrianba, paulc, pal, Aaron_Colwell, [Microsoft], +1.425.202.aaaa, ddorwin, johnsim, Mark_Watson, +1.303.661.aabb, BobLundRegretsChairPaul CottonScribeAdrian Bateman
Contents
•Topics 1.Role call, introduction, selection of scribe
2.Previous meeting minutes
3.Review of action items
4.Baseline documents
5.Progression to First Public Working Draft
6.Media Source Extensions bugs
7.Adjournment

•Summary of Action Items

--------------------------------------------------------------------------------




<trackbot> Date: 15 January 2013

<scribe> ScribeNick: adrianba

<scribe> Scribe: Adrian Bateman

Role call, introduction, selection of scribe

paulc: done

Previous meeting minutes

http://www.w3.org/2013/01/08-html-media-minutes.html


paulc: no comments

Review of action items

paulc: none for MSE

Baseline documents

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

Progression to First Public Working Draft

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

Media Source Extensions bugs

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

Adjournment

paulc: adjourned

Summary of Action Items
[End of minutes]

____________________________
From: Paul Cotton 
Sent: Monday, January 14, 2013 8:35 PM
To: public-html-media@w3.org
Cc: Adrian Bateman; David Dorwin <ddorwin@google.com> (ddorwin@google.com); Mark Watson; Aaron Colwell <acolwell@google.com> (acolwell@google.com)
Subject: {agenda} HTML WG media telecon 2013-01-15 - MSE and EME FPWDs, MSE bug status

The HTML WG media teleconference meeting will occur on 2013-01-15 for up to 60 minutes from 15:00Z to 16:00Z.

http://timeanddate.com/s/2aq7

Tokyo midnight, Amsterdam/Oslo 17:00, London/Dublin 16:00, New Jersey/York 11:00, Kansas City 10:00, Seattle/San Francisco 08:00.

Chair of the meeting: Paul Cotton
Scribe: TBD

(See the end of this email for dial-in and IRC info.)

== Agenda ==

1. Roll call, introductions and selection of scribe

2. Previous meeting minutes
http://www.w3.org/2013/01/08-html-media-minutes.html


3. Review of action items
https://www.w3.org/html/wg/media/track/

Status: None for MSE.

4. Baseline documents 

a) Encrypted Media Extensions editor’s draft
http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html

Status as of Jan 14:  Last updated on Jan 12.

b) Media Source Extensions editor's draft: 
http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html

Status as of Jan 14:  Last updated on Jan 4:
http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0001.html


5. Progression to First Public Working Draft

a) CfC: to publish Media Source Extensions specification as a First  Public Working Draft (FPWD)
http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0005.html 

b) Encrypted Media Extensions FPWD
Status: Awaiting progression on the following items:
- Bug 17199: Mark to do this week
See http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0011.html 
- Bug 17682: John to do this week and close out ACTION-9
<to be supplied>
- Bug 18531: David will do this week
DONE.  See: http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0014.html 
- Bug 20335: Adrian to do this week 6. 
See: http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0014.html 
Status: “There is still an open question of whether two states is enough, so this bug remains open.”
Candidate FPWD:
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html


6. Discussion of outstanding bugs

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

Status as of Jan 14: 9 bugs (see list at end of agenda)

b) [MSE] Rethinking MediaSource.setTrackInfo() and MediaSource.getSourceBuffer()
http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0007.html 

c) [MSE] Bug 18615 - HTMLMediaElement.buffered behavior in "ended" state
http://lists.w3.org/Archives/Public/public-html-media/2013Jan/0008.html


d) Other bugs identified for discussion

7. Other Business

8. Chair and Scribe for next meeting

9. Adjournment

== Dial-in and IRC Details ==

Zakim teleconference bridge:
   +1.617.761.6200, conference 63342 ("media")
https://www.w3.org/Guide/1998/08/teleconference-calendar#s_5366


Supplementary IRC chat (logged):
   #html-media on irc.w3.org port 6665 or port 80

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

ID▲ 
Product 
Comp 
Assignee 
Status 
Resolution 
Summary 
Changed 
20253 
HTML WG 
Media So 
acolwell 
ASSI 
--- 
Publish Media Source Extensions FPWD 
2012-12-13 
18400 
HTML WG 
Media So 
watsonm 
ASSI 
--- 
Define and document timestamp heuristics 
2012-12-28 
18592 
HTML WG 
Media So 
adrianba 
NEW 
--- 
How much is "enough data to ensure uninterrupted playback" 
2012-12-04 
18615 
HTML WG 
Media So 
acolwell 
ASSI 
--- 
Define how SourceBuffer.buffered maps to HTMLMediaElement.buffered 
2012-10-22 
18933 
HTML WG 
Media So 
watsonm 
ASSI 
--- 
Segment byte boundaries are not defined 
2012-12-28 
19673 
HTML WG 
Media So 
adrianba 
NEW 
--- 
Seamless audio signal transitions at splice points 
2012-12-18 
19676 
HTML WG 
Media So 
adrianba 
NEW 
--- 
timestampOffset accuracy 
Tue 17:01 
19784 
HTML WG 
Media So 
adrianba 
NEW 
--- 
timestampOffset with multiplexed Media Segments 
2012-12-18 
20327 
HTML WG 
Media So 
adrianba 
NEW 
--- 
Continuous splice flag 
2012-12-28 
9 bugs found.



Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

Received on Tuesday, 15 January 2013 17:35:11 UTC