- From: Adrian Bateman <adrianba@microsoft.com>
- Date: Tue, 23 Jul 2013 16:24:49 +0000
- To: Paul Cotton <Paul.Cotton@microsoft.com>, "public-html-media@w3.org" <public-html-media@w3.org>
- CC: "Aaron Colwell <acolwell@google.com> (acolwell@google.com)" <acolwell@google.com>, Mark Watson <watsonm@netflix.com>
Minutes -> http://www.w3.org/2013/07/23-html-media-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
HTML Media Task Force Teleconference
23 Jul 2013
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-html-media/2013Jul/0013.html
See also: [3]IRC log
[3] http://www.w3.org/2013/07/23-html-media-irc
Attendees
Present
pladd, glenn, +1.831.457.aaaa, Michael_Thornburgh,
+1.650.458.aabb, ReimundoGarcia, +44.173.776.aacc,
paulc, Aaron_Colwell, [Microsoft], adrianba, pal,
stevep, +1.303.661.aadd, BobLund
Regrets
Chair
Paul Cotton
Scribe
Adrian Bateman
Contents
* [4]Topics
1. [5]Roll call, introductions and selection of scribe
2. [6]Previous meeting minutes
3. [7]Review of action items and issues
4. [8]Media Source Extensions editor's draft
5. [9]Pre-Last Call bugs
6. [10]Bug 22137 - changes in number of audio tracks
during advert insertion
7. [11]Bug 22136 - Inband Storage for SPS/PPS in ISO BMFF
8. [12]MSE Last Call or heart beat Working Draft
publication
9. [13]Candidate Last Call bugs
10. [14]Any other business
11. [15]Adjournment
* [16]Summary of Action Items
__________________________________________________________
<trackbot> Date: 23 July 2013
<scribe> ScribeNick: adrianba
<scribe> Scribe: Adrian Bateman
Roll call, introductions and selection of scribe
paulc: done
<paulc> Agenda:
[17]http://lists.w3.org/Archives/Public/public-html-media/2013J
ul/0013.html
[17] http://lists.w3.org/Archives/Public/public-html-media/2013Jul/0013.html
Previous meeting minutes
paulc: don't think they need any discussion - used to drive the
agenda
Review of action items and issues
paulc: all in the agenda
Media Source Extensions editor's draft
<paulc>
[18]https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source
/media-source.html
[18] https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
paulc: updated once by aaron on july 18 - sent a note about
changes
Pre-Last Call bugs
<paulc> [19]http://tinyurl.com/6pdnzej
[19] http://tinyurl.com/6pdnzej
paulc: divided bugs between pre-last call bugs and then last
call - if we have time we'll look at the candidate last call
bugs
Bug 22137 - changes in number of audio tracks during advert insertion
ACTION-21?
<trackbot> ACTION-21 -- Adrian Bateman to work with Jerry to
review bug 22137 and provide feedback -- due 2013-07-02 --
CLOSED
<trackbot> [20]http://www.w3.org/html/wg/media/track/actions/21
[20] http://www.w3.org/html/wg/media/track/actions/21
<paulc>
[21]https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137#c8
[21] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137#c8
[22]https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137
[22] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137
paulc: comments suggest won't fixing?
acolwell: yes, i'm proposing that we create a different spec to
handle track switching independently
... so that other html5 media can take advantage of it
... the comments after comment 8 talk about what situations
could arise
... my position is that i agree there could be problems but we
should make this another spec because it is an independent
issue
... agree with adrian's earlier comment suggesting marking as
Won't Fix
<Michael_Thornburgh> i'm on the phone too
paulc: one of the correspondents is Michael_Thornburgh
... do you want to make comments?
Michael_Thornburgh: my concerns is mostly making sure the use
case is addressed
... if the solution is another spec to make it possible that's
okay
... i'm particularly concerned that the stalling behaviour is
part of the MSE spec
... and you want to avoid stalls at append time
... if in some proposed solution in a different spec that
allows for timed track switching, this correctly maps to append
time stalling behaviour then that would be okay
acolwell: my intention was that MSE talks about what tracks are
taking into account during playback
... so stalls only happen if tracks playing don't have content
... this other proposed mechanism would specify when the switch
happens
... and track switch would happen as if they were being done
instantly
... but because you provide the data ahead of time, the media
engine knows a switch is coming up
... however that spec addresses switching then it will allow
for a window around the switch where it doesn't have to match
exactly
Michael_Thornburgh: that sounds reasonable
<pal> is this great information provided by Aaron captured
somewhere in the specification?
acolwell: to pal's question, how stalls happened and what
happens when a track is enabled or disabled is in the spec
... so this new spec would specify a track switch in terms of
how tracks currently are enabled or disabled
... so MSE would work with that
... tracks enabled get added to active source buffers and
affect stalling
<Michael_Thornburgh> +q
acolwell: when removed gets removed from active source buffers
and doesn't have to have data for playback
Michael_Thornburgh: the other issue is having more than two
sourcebuffers
... probably ought to be some indication in the spec that
sourcebuffers > 2 should be supported
acolwell: i have concerns about mandating that
adrianba: IE11 supports more than two sourcebuffers
acolwell: i have concerns about specifying how many need to be
supported - this is a quality of implementation issue
... don't need to put this in the spec
pal: section 2.2 requires 3 source buffers, right?
acolwell: that's not at the same time
pal: think there should be an OR in the spec - reader probably
thinks it is an AND
... if we think use case A is essential but the spec doesn't
mandate the requirement for use case A then it isn't a quality
of implementation issue
BobLund: i agree with what pierre just said
... if this is a must to support then a requirement is there
<Michael_Thornburgh> Bob said what i was about to say
BobLund: what about non-normative text that lays out the use
case and explains the need for support for more source buffers
paulc: have we strayed away from the original bug?
Michael_Thornburgh: marking this won't fix should be contingent
on another spec
paulc: would someone take an action to file an HTML5 bug
proposing to solve in HTML 5.1 or a separate extension spec
... do the editors know what kind of non-normative text would
be required?
acolwell: no, this would be the first case of doing this - some
example text would be useful
paulc: adrian, do you have an idea?
adrianba: happy to take an action to add some text - don't
think it is needed but if it is needed to get consensus to
resolve this bug then okay
paulc: does anyone want to volunteer to file the bug for the
other use case
Michael_Thornburgh: i will file that bug
<pal> should I file a bug against Section 2.2 re: there should
be an "OR"
<scribe> ACTION: Michael_Thornburgh to file bug describing
timed track changes [recorded in
[23]http://www.w3.org/2013/07/23-html-media-minutes.html#action
01]
<trackbot> Error finding 'Michael_Thornburgh'. You can review
and register nicknames at
<[24]http://www.w3.org/html/wg/media/track/users>.
[24] http://www.w3.org/html/wg/media/track/users%3E.
paulc: this will send mail to public-html-admin - you could
send mail to public-html asking for people's opinions about if
such a spec would be useful
adrianba: seems like it would be in scope for the media task
force too
paulc: yes, but i think we want to get broad review
pal, sure - create the editorial bug - will deal as LC issue
<scribe> ACTION: adrianba to propose non-normative text and
resolve 22137 [recorded in
[25]http://www.w3.org/2013/07/23-html-media-minutes.html#action
02]
<trackbot> Created ACTION-28 - Propose non-normative text and
resolve 22137 [on Adrian Bateman - due 2013-07-30].
pal: happy to create a bug for the OR issue
paulc: believe that resolves 22137
Bug 22136 - Inband Storage for SPS/PPS in ISO BMFF
[26]https://www.w3.org/Bugs/Public/show_bug.cgi?id=22136
[26] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22136
ACTION-22?
<trackbot> ACTION-22 -- Adrian Bateman to work with jerry to
confirm the proposal in 22136 is acceptable -- due 2013-07-02
-- OPEN
<trackbot> [27]http://www.w3.org/html/wg/media/track/actions/22
[27] http://www.w3.org/html/wg/media/track/actions/22
jdsmith: i had asserted that the standard wasn't mature enough
but we're withdrawing that
... it is as mature as our spec
... i propose a SHOULD and proposed text in the bug
<paulc> Proposed text:
[28]https://www.w3.org/Bugs/Public/show_bug.cgi?id=22136#c13
[28] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22136#c13
jdsmith: think aaron's proposal is pretty close
stevep: could of things we notice - one is that switching from
SPS/PPS it could be made more generic
... HEVC allows other things in that configuration record
... we'd like it to be a MUST
... for interop reasons
... so that implementations can process any content
paulc: reason for MUST for the first and SHOULD for the second?
jdsmith: the first is an existing standard - we think the draft
requires decoders to support this in multiple locations
paulc: usually discourage groups from arguing over MUST and
SHOULD this early
... one idea would be to make them both MUST and then mark at
risk
acolwell: we should probably rework the text based on my recent
fixes to the byte stream format so that it is in terms of what
the user agent should do
... sounds like this is about complying content so we need to
rework into "the UA must do" style
paulc: which bug caused this?
acolwell: 22117
[29]https://www.w3.org/Bugs/Public/show_bug.cgi?id=22117
[29] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22117
paulc: whatever text we have, this needs to be looked at in the
context of that bug
adrianba: this whole section is optional in the spec - won't
come into play for CR exit criteria
paulc: bbc is asking for a MUST and for the reference to be
changed
pal: section 12.2 is only for the implementations that choose
to do so
... if you choose to do this - SHOULD vs. MUST
adrianba: can live with it but don't think this will affect
implementations
stevep: our tests suggest this is easy to implement
acolwell: agree with adrian - can live with must but if we run
across implementations that can't support with hardware then
they won't do this - you can put a MUST but it doesn't mean all
implementations will do it - we will be constrained by devices
pal: to the original question - concerned that there are two
implementers saying it cannot be implemented
... from a content creation standpoint - if it says MUST i can
assume it is always there but it might not be there and that is
something i should know
... SHOULD means probably there but might not be
<ReimundoGarcia> should
paulc: is there anyone that can't live with it being a SHOULD?
<paulc> steve
stevep: our problem is that a SHOULD means that things that
could implement it won't
... we won't serve to devices that don't support it
acolwell: don't think we can answer this question right now
<pal> waht about adding a note stating that DASH requires this
feature?
acolwell: as implementers have concerns that there would be
devices we could support MSE on without this
... we should indicate that this might not be supported - could
change to MUST later
pal: what about adding a note saying this feature is required
in this other specification
acolwell: don't believe MSE says it must be able to support all
of DASH
adrianba: proposal: make this a should with a note that
describes that DASH content might not play back without this
support
paulc: you'll get to see the text and can file a last call
comment
... proposal is editors 22136 resolved as fix with text that
was proposed by jerry, amended with note that DASH content
might not playback with this support, also amended with aaron's
comment about in terms of UA
<scribe> ACTION: acolwell to work with jerry to add text for
22136 into the spec [recorded in
[30]http://www.w3.org/2013/07/23-html-media-minutes.html#action
03]
<trackbot> Created ACTION-29 - Work with jerry to add text for
22136 into the spec [on Aaron Colwell - due 2013-07-30].
MSE Last Call or heart beat Working Draft publication
paulc: chairs are trying to get heartbeat publications for all
drafts
[31]http://lists.w3.org/Archives/Public/www-archive/2013Jul/004
0.html
[31] http://lists.w3.org/Archives/Public/www-archive/2013Jul/0040.html
scribe: leaving heartbeat to one side, we anticipated that at
this stage we'd ask the task force and then the working group
to go into last call
... we need to ask the editors to create an last call draft at
a unique URL
... then ask the task force for approval to forward to WG for a
CfC
... how long will it take the editor's to produce the last
call?
acolwell: won't take long once we have the two edits done
... an hour or less after that we have the doc
paulc: we can get approval from TF either through email or do
it in two weeks at the meeting
... recommend that the TF permits me to do whichever occurs
earlier
... if editors get draft done this week - run a CfC by email so
we get done as early as possible
... otherwise we can do it at the next meeting
... so worst case approve no later than 2 weeks from now
acolwell: works for me
+1
paulc: antipating editors will close out these two bugs and
announce they are done - if they supply me with a candidate LC
doc i will start CfC in TF
... after that closes will discuss with co-chairs
... and make sure happens at WG level
... clear?
Candidate Last Call bugs
paulc: 22432 and 22371
... both dealt with at jul 2 meeting
... proposed no change to 22432 - not implemented
... 22371, aaron was going to respond to the bug
acolwell: haven't done yet - need to respond in the bug
proposing it be created in a new doc
paulc: like to suggest that editors go back and look at
previous minutes and update bugs to say what our position is
... if someone objects to LC because of these bugs i would
overrule because they came in after pre-LC but i think it is
good practice to add current status in the bug
Any other business
<pal> have a nice day
paulc: very close to last call
... will tell my co-chairs that we're planning to go to LC and
won't need heartbeat
Adjournment
paulc: we're done
Summary of Action Items
[NEW] ACTION: acolwell to work with jerry to add text for 22136
into the spec [recorded in
[32]http://www.w3.org/2013/07/23-html-media-minutes.html#action
03]
[NEW] ACTION: adrianba to propose non-normative text and
resolve 22137 [recorded in
[33]http://www.w3.org/2013/07/23-html-media-minutes.html#action
02]
[NEW] ACTION: Michael_Thornburgh to file bug describing timed
track changes [recorded in
[34]http://www.w3.org/2013/07/23-html-media-minutes.html#action
01]
[End of minutes]
__________________
From: Paul Cotton
Sent: Monday, July 22, 2013 6:06 PM
To: public-html-media@w3.org
Cc: Aaron Colwell <acolwell@google.com> (acolwell@google.com); Adrian Bateman; Mark Watson
Subject: {agenda} HTML WG media telecon 2013-07-23 - MSE status and bug discussion
The HTML WG media teleconference meeting will occur on 2013-07-23 for up to 60 minutes from 15:00Z to 16:00Z.
http://timeanddate.com/s/2e54
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/07/09-html-media-minutes.html
3. Review of action items and issues
https://www.w3.org/html/wg/media/track/
MSE-related actions are given below.
4. MSE status and bugs
a) Media Source Extensions editor's draft:
http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
Status as of Jul 22: Last updated on Jul 18.
b) Media Source Extensions bugs:
http://tinyurl.com/6pdnzej
Status as of Jul 22: 4 bugs. See list at end of this agenda.
5. Pre-Last Call bugs
a) Bug 22137 - changes in number of audio tracks during advert insertion
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137
ACTION-21: Work with Jerry to review bug 22137 and provide feedback
https://www.w3.org/html/wg/media/track/actions/21
Status: Closed. See Aarron’s response and subsequent responses:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22137#c8
b) Bug 22136 - Inband Storage for SPS/PPS in ISO BMFF
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22136
ACTION-22: Work with jerry to confirm the proposal in 22136 is acceptable
https://www.w3.org/html/wg/media/track/actions/22
6. MSE Last Call or heart beat Working Draft publication
http://lists.w3.org/Archives/Public/www-archive/2013Jul/0040.html
7. Candidate Last Call bugs
a) Bug 22432 - Allow SourceBuffer.appendBuffer to take ownership of the ArrayBuffer
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22432
Status: Candidate Last Call bug. Jul 2 meeting proposed no change to spec but not yet implemented.
b) Bug 22371 - [MSE] Ogg byte streams
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22371
Status: Candidate Last Call bug. Aaron offered to respond at the Jul 2 meeting.
8. Any other business
9. Chair and Scribe for next meeting
10. 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▼
Assignee
Status
Summary
Changed
22432
adrianba@microsoft.com
NEW
Allow SourceBuffer.appendBuffer to take ownership of the ArrayBuffer
2013-06-24
22371
acolwell@google.com
ASSI
[MSE] Ogg byte streams
2013-06-25
22137
adrianba@microsoft.com
NEW
changes in number of audio tracks during advert insertion
2013-06-17
22136
acolwell@google.com
ASSI
Inband Storage for SPS/PPS in ISO BMFF
2013-06-11
4 bugs found.
Received on Tuesday, 23 July 2013 16:26:53 UTC