- From: Adrian Bateman <adrianba@microsoft.com>
- Date: Tue, 23 Oct 2012 16:06:31 +0000
- To: Paul Cotton <Paul.Cotton@microsoft.com>, "public-html-media@w3.org" <public-html-media@w3.org>
Minutes -> http://www.w3.org/2012/10/23-html-media-minutes.html
- DRAFT -
HTML Media Task Force Teleconference
23 Oct 2012
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0053.html
See also: [3]IRC log
[3] http://www.w3.org/2012/10/23-html-media-irc
Attendees
Present
+1.650.525.aaaa, pal, Matt, +1.415.867.aabb, paulc,
adrianba, [GVoice], strobe, [Microsoft], johnsim,
Aaron_Colwell, +1.303.661.aacc, markw
Regrets
Chair
Paul Cotton
Scribe
Adrian Bateman
Contents
* [4]Topics
1. [5]Roll call, introductions, selection of scribe
2. [6]Previous meeting minutes
3. [7]Review of action items
4. [8]Baseline documents and Bugzilla information
5. [9]TPAC F2F discussion plans
6. [10]adjournment
* [11]Summary of Action Items
__________________________________________________________
<trackbot> Date: 23 October 2012
<scribe> ScribeNick: adrianba
<scribe> Scribe: Adrian Bateman
<scribe> Agenda:
[12]http://lists.w3.org/Archives/Public/public-html-media/2012O
ct/0053.html
[12] http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0053.html
<strobe> (wait, I may be GVoice instead, let me reassociate)
Roll call, introductions, selection of scribe
paulc: done
Previous meeting minutes
paulc: the most significant thing was that we agreed to triage
bugs and Aaron indicated he would update the spec
... these are on the agenda
Review of action items
ACTION-6?
<trackbot> ACTION-6 -- Aaron Colwell to give a couple of
examples for section 2 -- due 2012-09-04 -- OPEN
<trackbot> [13]http://www.w3.org/html/wg/media/track/actions/6
[13] http://www.w3.org/html/wg/media/track/actions/6
paulc: this is still outstanding, correct?
acolwell: we discussed this amongst the editors but not shared
anything public
ACTION-6 due nov 1
<trackbot> ACTION-6 Give a couple of examples for section 2 due
date now nov 1
Baseline documents and Bugzilla information
[14]http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/
media-source.html
[14] http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
paulc: Last updated Oct 18
[15]http://lists.w3.org/Archives/Public/public-html-media/2012O
ct/0039.html
[15] http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0039.html
paulc: aaron do you want to say anything about this?
acolwell: the changes might be surprising because i split up
the algorithm a bit to make it easier to understand
... there isn't really a functional change - should just take a
look at this change
... added initial description of remove()
... doing more to this is on the agenda for tpac
... also updated media format section with more clarifications
TPAC F2F discussion plans
paulc: two weeks ago the editors proposed to triage the
existing bugs
... they've done this
... the attachment to the mail from the editors indicates the
current status of bugs broken down into clarifications or new
features
... and identifies the ones we want to discuss
... the first observation we should make is that the editors
have resolved some of the bugs
... the majority of the new features are on the TPAC discussion
list
... i don't think we need to drill on the bugs resolved
... one or more were resolved NEEDSINFO
... let's deal with them at a high level
acolwell: 18922, request to have a better example that is codec
and format agnostic
... initially responded that the API expects you to know the
format, resolved asking for a better example that you'd like to
see since we don't think we can do this
... but please give an example of what you'd like to see
... 18921, we think this is a misunderstanding of the goal of
the API - this was requested adding arbitrary media data but
the API requires you to know something about the data
... 18920, we discussed this on the call and the consensus was
to keep the type parameter to allow UAs to fail fast
... 17000, we decided to defer this one because we don't have a
great idea of what this should entail
... those are all the ones resolved
paulc: my plan is that we won't revisit these at TPAC - if
anyone has objections to the resolutions then they should
reopen the bug with their problem statement
... next we should go on to the items for discussion at TPAC
acolwell: 18592, how much data to ensure uninterrupted playback
... this is about how appending data to the sourcebuffer
affects the HTML media element readystate
... some discussion in the bug, there are trade-offs between
different solutions, which we should discuss
... this might affect autoplay, for example, and we need to
decide if and how to handle this
... 18575, this is related to ACTION-6
... i sent something to the editors about this, which i can
publish beforehand to help the discussion
... some parts of section 2 are covered by algorithms and might
be deleted
... other parts might be moved to other areas
... and some we need to figure out how to rewrite them
... then we can discuss including at TPAC
... the main thing is to understand the balance between
normative and informative
paulc: let's get that out quickly
acolwell: that's fine - it's basically a copy and paste
... 18601, this is the topic from a couple of calls ago
... main goal is to close this discussion
... particularly about how to handle transport streams
... 18960, specifying how track IDs are generated
paulc: does the bug here point to the HTML5 bug?
acolwell: no, i'll find that - i think the bug is relevant to
17002
... this got deferred to HTML.next
paulc: i wonder if we should ask for that bug to be discussed
by HTML WG as a whole
... because we don't want the media topics discussed if we need
that discussed by a broader group
acolwell: that's fine
<acolwell>
[16]https://www.w3.org/Bugs/Public/show_bug.cgi?id=18971
[16] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18971
paulc: if we have the bug number we can organise that
acolwell: discussion for 18960 is to figure out how to generate
the IDs
... in some cases can be the track ID in the media
... for single video/audio track media we need to define the
behaviour
... two proposals, one is to generate IDs, one is to use the
first
... 19531, this is a recently filed bug about detecting which
MIME types are actually supported by MSE
... proposal in the bug and discussion about the name and
semantics of the method
... just need to nail this down, shouldn't take too long
... so those are the ones in the clarification category
... in the new features category
... 18962, a mechanism for rate limiting where the tag can tell
the app to slow down
... not much discussion about this, discussion for TPAC is if
we need this in v1
... and if yes to come up with a proposal
... questions so far?
paulc: nobody on the queue
... btw updated the TPAC wiki to mention 18971 - we might have
a session to deal with misc bugs
acolwell: 18962, this is making progress on the XHR integration
with MSE
... since the last time we discussed there is progress on the
webapps
... with people starting to rally around the microsoft proposal
... there is some discussion about how the W3C spec will get
updated
... and behaviours about what MSE should do with this object
... 18709, about SourceBuffer.remove() that i recently added
... need to discuss the behaviour if remove is requested for
current playback range
... not clear what to do if the app wants to remove content at
the current position
... 17006, this is about specifying the track language and kind
when not available
adrianba: i will make a proposal prior to TPAC so we have
something concrete to discuss
... i think we know what the problem is and what is needed - we
just need someone to make a concrete proposal and i will do
that
acolwell: 17002, this is how to figure out which buffer is
associated with a track - think we have a rough proposal that
we need to finalise
... track might not have an ID and we need to figure out what
to do as a workaround
... 17094, this is to talk about MPEG2-TS - get some face to
face discussion on this
... there has been some email discussion but some face to face
discussion might help it go easier
paulc: do the editors know how long it will take to discuss
these? will 90 mins be sufficient or will we need more time
acolwell: i think we might need more - can we have an optional
extension?
paulc: we won't necessarily be able to tell until we see what
slots are needed
... interestingly many a11y people will be in indieui
... which in the past we spent a lot of time on
... i don't think that will happen this time
... if there is time we might want to extend the slot but we'll
need to do that there
<paulc> F2F topics:
[17]http://www.w3.org/html/wg/wiki/TPAC2012#Topics
[17] http://www.w3.org/html/wg/wiki/TPAC2012#Topics
acolwell: we should also take a poll of people at the meeting
to discuss the highest priority items
paulc: pierre, your items, first audio splicing
<paulc> MSE audio splicing:
[18]http://lists.w3.org/Archives/Public/public-html-media/2012O
ct/0052.html
[18] http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0052.html
pal: the idea here is that given the scope of MSE and use cases
considered
... it would be good to try to look at a topic previously
frustrating
... which is the splicing of audio or transition of audio
streams at splice points
... for video you transition at video frame boundary
... but audio is more difficult, for example if the audio
levels are different
... for encoded audio the frame boundaries might not line up
... so goal is to capture some practices that have been learned
and share with implementers
... i think it would be help to have something along those
lines provided to MSE implementers
adrianba: is this proposal for informative text or should part
of it be normative?
pal: that's up to this group - either could work, i don't have
an extremely strong opinion
... just listing them will reduce poor implementation and lack
of interop
adrianba: if this would affect interop it sounds like there
would be normative parts
acolwell: i've only done a high level review - seems like some
of the parts of splicing encoded data would be good to be
normative
... current text is light on this topic
... but haven't drilled into which text should be normative
paulc: do we want to do anything on this before the meeting?
acolwell: i plan to read the doc more carefully
... i haven't spent much time thinking about audio
pal: my recommendation is that this be included or be
considered before FPWD
... the longer we wait the more likely decisions that people
might regret could be made
... some might not be relevant, some might need more detail,
i'm happy to help
... but it should be addressed before FPWD
paulc: what's the rationale for that? is it because of the
scope
pal: i think implementers might take decisions
... that might be hard to undo
paulc: for fpwd you only have to have agreement to publish not
to that on the content
pal: it's better to have a better FPWD
paulc: i'm not arguing against, just trying to understand
adrianba: i think we should prioritise identifying the
normative parts for the FPWD so that the scope is set
... that's the most important activity for this
Mark_Vickers: it's not clear which parts are authoring and
client parts, could that be clearer?
acolwell: i think they're all UA requirements
Mark_Vickers: in 2.1 it says content should be authored
pal: it was meant as a client recommendation
... you're right that there are two points that menton
authoring
... but that is meant as a help to the reader
... but this was meant as client behaviour which would then
drive authoring behaviour
Mark_Vickers: okay, thanks
pal: important part is that unless some of these are documented
for client authors will not know how to get the desired outcome
Mark_Vickers: i think there's a lot of experience to show that
this has caused problems in the past
... and i support the idea of getting this out earlier
paulc: next item is timestamp offset accurary
<paulc> See:
[19]http://lists.w3.org/Archives/Public/public-html-media/2012O
ct/0054.html
[19] http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0054.html
pal: before that, part of outcome of splicing is benefit of
adding flag to each buffer appended
... so may need to add a flag to buffers but we can discuss as
part of document
paulc: okay, let's move on to timestamp offset accuracy, which
you've had one reply to
pal: this has cause problems in the past
... offsets are often specified in sample durations
... unfortunately floating point representation cannot in
general represent fractions because of rounding errors
... this is a tricky area and direction i've seen is to express
offset and positions as rational numbers instead of floating
point numbers
... MSE uses double for the offsets
... timestampOffset is a double
... i think it should be expressed as a rational number without
ambiguity
... how the implementation uses that is different and spec
might not talk about that
paulc: by rational do you mean specifying numerator and
denominator
pal: that's one way, alternative is timescale (ratio) and then
multiple of timescale
... by rational i mean the ratio between integers
... e.g. ISO BMFF uses two integers
... this is a topic that caused issues and i want to understand
if this is an issue here and then figure out a solution
<paulc> ack +
strobe: timestampOffset is the last thing applied
... i think a lot of past problems with precision have come for
duration calculation
... we need a common way of expressing all the possible inputs
... even if you had very precise ways of specifying for one
file
... you might be using different files and you need the
precision for all of them
... since this is just for offset not for duration i don't
think it will cause a problem based on my experience
adrianba: please could pal file bugs in bugzilla, which we'll
use to drive the discussion in the meeting
paulc: we've dealt with these topics, okay?
pal: yes, thanks
strobe: one quick question, the states in which you can add and
remove sourcebuffers
... i think we discussed this in the past
acolwell: i think we said you could do this at any time
... at the moment chrome doesn't support that because of
limitations in the engine
... i don't know if we want to support that in the API
... but for now chrome doesn't support that
strobe: okay, thanks
paulc: think we've covered all of the agenda
... we have a plan in place for a good discussion at tpac
... is there other business to discuss?
... future meeting schedule
... won't be EME next week
... schedule would normally be for a MSE meeting right after
TPAC
... i doubt we'll want to meet so soon after the F2F
... we want to give the editors time
... we'll discuss this at the meeting
... i'm also on vacation during november
... so we need to discuss who will drive the meetings too
... we'll discuss at tpac
adjournment
paulc: meeting is adjourned
... thanks to the editors for analysis
... let's hope for the same on EME
Summary of Action Items
[End of minutes]
__________________
From: Paul Cotton [mailto:Paul.Cotton@microsoft.com]
Sent: Monday, October 22, 2012 12:44 PM
To: public-html-media@w3.org
Subject: {agenda} HTML WG media telecon 2012-10-23 - media source extension bugs and TPAC preparations
The HTML WG media teleconference meeting will occur on 2012-10-23 for up to 60 minutes from 15:00Z to 16:00Z.
http://timeanddate.com/s/29yu
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/2012/10/09-html-media-minutes.html
3. Review of action items
https://www.w3.org/html/wg/media/track/
a) Bug 18785: ACTION-6: Give a couple of examples for section 2, Aaron
https://www.w3.org/html/wg/media/track/actions/6
4. Baseline documents and Bugzilla information
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 Oct 22: Last updated in Oct 18.
http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0039.html
b) Media Source Extension bugs:
http://tinyurl.com/6pdnzej
Status as of Oct 7: 16 bugs
4. TPAC F2F discussion plans
http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0051.html
and
http://lists.w3.org/Archives/Public/public-html-media/2012Oct/att-0051/mse-bugs.htm
5. Other Business
6. Chair and Scribe for next meeting
Note: Paul will be on vacation after TPAC for 3 weeks ie Nov 3-25.
7. 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
16 bugs found.
ID▲
Product
Comp
Assignee▲
Status▲
Resolution
Summary
Changed
17002
HTML WG
Media So
adrianba@microsoft.com
NEW
---
Specify a mechanism to determine which SourceBuffer an AudioTrack,VideoTrack, or TextTrack belong to.
02:43:58
18592
HTML WG
Media So
adrianba@microsoft.com
NEW
---
How much is "enough data to ensure uninterrupted playback"
Mon 01:01
18709
HTML WG
Media So
adrianba@microsoft.com
NEW
---
Add SourceBuffer.remove() method
02:39:39
18960
HTML WG
Media So
adrianba@microsoft.com
NEW
---
Define how AudioTrack.id & VideoTrack.id are generated
02:43:58
18962
HTML WG
Media So
adrianba@microsoft.com
NEW
---
Allow appending with XHR
02:37:41
18963
HTML WG
Media So
adrianba@microsoft.com
NEW
---
Provide a mechanism for rate limiting appending
02:29:51
19531
HTML WG
Media So
adrianba@microsoft.com
NEW
---
simplify MIME type capability detection
08:29:47
18575
HTML WG
Media So
acolwell@chromium.org
ASSI
---
Section 2. Source Buffer Model should be non-normative
Mon 01:07
18587
HTML WG
Media So
acolwell@chromium.org
ASSI
---
Define clearly what data is removed when setting an explicit duration
Mon 01:23
18601
HTML WG
Media So
acolwell@chromium.org
ASSI
---
Contradictory requirements for initialization segments
Mon 01:14
18615
HTML WG
Media So
acolwell@chromium.org
ASSI
---
Define how SourceBuffer.buffered maps to HTMLMediaElement.buffered
Mon 00:53
18642
HTML WG
Media So
acolwell@chromium.org
ASSI
---
Handle timestamp overflow in append(data)
16:00:32
17006
HTML WG
Media So
adrianba@microsoft.com
ASSI
---
<track> Setting track language & kind when the information is in a manifest
02:41:41
17094
HTML WG
Media So
b.lund@cablelabs.com
ASSI
---
Define segment formats for MPEG2-TS
02:56:25
18400
HTML WG
Media So
watsonm@netflix.com
ASSI
---
Define and document timestamp heuristics
16:00:32
18933
HTML WG
Media So
watsonm@netflix.com
ASSI
---
Segment byte boundaries are not defined
Sun 15:47
16 bugs found.
Received on Tuesday, 23 October 2012 16:10:27 UTC