- From: Adrian Bateman <adrianba@microsoft.com>
- Date: Tue, 9 Apr 2013 16:19:58 +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>, "Pierre-Anthony Lemieux (pal@sandflow.com)" <pal@sandflow.com>
Minutes -> http://www.w3.org/2013/04/09-html-media-minutes.html
- DRAFT -
HTML Media Task Force Teleconference
09 Apr 2013
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-html-media/2013Apr/0039.html
See also: [3]IRC log
[3] http://www.w3.org/2013/04/09-html-media-irc
Attendees
Present
Michael_Thornburgh, glenn, pal, Bin, markw, [Microsoft],
Aaron_Colwell, +1.404.269.aaaa, ReimundoGarcia, ddorwin,
BobLund, adrianba, Bin_Hu
Regrets
Chair
aaron colwell
Scribe
adrian bateman
Contents
* [4]Topics
1. [5]CfC: to publish a heartbeat Media Source Extensions
Working Draft
2. [6]F2F meeting topics
3. [7]Discussion of outstanding bugs
4. [8]out of order appends
5. [9]Adjournment
* [10]Summary of Action Items
__________________________________________________________
<trackbot> Date: 09 April 2013
<markw> I guess Paul cannot make it. Anyone want t chair ?
<markw> (I'm on a bus - noisy - otherwise I'd volunteer)
<acolwell> I can chair
<markw> hooray, we can start ;-)
<scribe> scribenick: adrianba
<scribe> scribe: adrian bateman
acolwell: i published an updated version of the spec with 5 bug
fixes
... mostly clarifications, nothing too huge
CfC: to publish a heartbeat Media Source Extensions Working Draft
WG Decision:
[11]http://lists.w3.org/Archives/Public/public-html-admin/2013A
pr/0023.html
[11] http://lists.w3.org/Archives/Public/public-html-admin/2013Apr/0023.html
adrianba: think we need to work with Robin or Mike to get this
published
F2F meeting topics
acolwell: thought we could talk about what we need to do to get
to last call
... seems like the bug count is pretty low
... do we want the slot at the face-to-face?
adrianba: i'd like to see us make progress towards LC
... perhaps we can give notice to the WG that we're getting
close
pal: would like to do this on the 23rd at the f2f
acolwell: think we can put in a request for the 23rd but it
might not be decided before everyone is in the room
adrianba: does anyone on the call object to requesting 23rd?
perhaps we could add this to the wiki
acolwell: not hearing any objections
... anything else about the f2f meeting?
Discussion of outstanding bugs
adrianba: would like to discuss out of order appends in this
section
acolwell: let's address that after the others
Bug 20760: <video> Expose statistics for tracking playback
quality
[12]https://www.w3.org/Bugs/Public/show_bug.cgi?id=20760
[12] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20760
markw: discussion has a tendency to grow out of control - is a
real problem related to adaptive streaming
... for some devices that can't play high quality videos
[lost some of the comment at the end]
adrianba: two issues - are the metrics the correct ones and
where should it be specified
... on the first, i think i'd like to see more discussion on
the detail of the proposal
... on the second, i think this is clearly tied to key use
cases for MSE, we've asked in the past to include this in an
appendix so it gets done, but we'll be guided by the consensus
of the WG for where it is written down
acolwell: my main concern is that there currently isn't a
mechanism for recording statistics on media element
... and if the HTML WG decides to specify that then there might
be two
... i'd like to get consensus for how to expose this and then
decide where to put it
markw: i think we probably should have a target that there is
something comprehensive on the element
... the discussion is quite a long way from going somewhere in
the WG
... don't think there is much chance of this going forward
quickly
... think this is important for deployments of MSE and we need
this implementation experience to drive the spec forward
... would like to see something in MSE with the understanding
it might be replaced in future
adrianba: we are the HTML WG and the full WG needs to agree
with the output from the TF'
s/TFTF/
acolwell: next step is to solicit comments from the WG?
adrianba: yes
Bug 19676 - timestampOffset accuracy
[13]https://www.w3.org/Bugs/Public/show_bug.cgi?id=19676
[13] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19676
<acolwell>
[14]https://www.w3.org/Bugs/Public/show_bug.cgi?id=19676
[14] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19676
acolwell: let's go to this one since pal wants to talk to it
pal: subject of lengthy discussion
... in the last comment, editor suggests additional
implementation experience is necessary
... my first suggestion is that in that case the bug should be
kept open and not closed
acolwell: i could mark as resolved later instead of resolved
fixed
... that's how we marked some other things
... trying to drive the bug count to zero
... to get to LC
pal: sympathise with the desire to mark as resolved
... but don't see how this is done
glenn: prefer to resolve as fixed and open a new bug in future
... to vague to say needs implementation experience
... that's the purpose of CR phase
adrianba: agree with glenn
pal: glenn and adrian, don't believe this is a subjective
question, very much mathematical
... spec says as accurate as possible
... bug was opened because of accuracy of timestamp
... comfortable with seeing how implementations work around
that but uncomfortable saying this is resolved
glenn: my experience, we make decisions in a somewhat
speculative manner and then move to implementation phase and
open new bugs if we find them
... problem is lack of specific change to make other than
keeping open
pal: very early in the thread there is a very specific
suggestion for how to resolve
adrianba: if there is a concrete text alternative proposal then
i think you should reopen the bug
... there is a process within the WG to resolve the situation
when
... there is not a clear consensus for what the spec should say
... if we have differing proposals the chairs will run this
process
... to decide what the spec should say
acolwell: i believe i addressed the suggestion for rationals in
comment 9
[15]https://www.w3.org/Bugs/Public/show_bug.cgi?id=19676#c9
[15] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19676#c9
acolwell: using a single rational doesn't solve the problem
because of if you mix content of different frame rates
... i believe the spec text provides sufficient mechanism to be
close enough
... and avoid the problem of if a frame is slightly after the
last frame it would get removed
... i think the time differences because of using the double
would not be perceivable by the user
... that's why i think implementation experience is needed
... all implementations will likely round to some precision
... and it will be too difficult to specify precisely how
different implementations will do this rounding
pal: i agree, fine with waiting for implementations
... what i wanted to bring up was marking a bug as resolved
when it looks like additional experience is needed doesn't feel
right
acolwell: as i say, i could resolve as later
pal: this would help look back at the end at the bugs we
weren't sure of
... sounds reasonable to me
acolwell: okay with everyone else?
... does anyone object to resolving this as LATER
adrianba: no objection
acolwell: not hearing anything - just updated the bug, now
RESOLVED LATER
Bug 21298 - Clarify relationship between SourceBuffer, input
buffer, and tracks
[16]https://www.w3.org/Bugs/Public/show_bug.cgi?id=21298
[16] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21298
acolwell: two parts to this
... one is a request for a diagram showing how appended data
moves through MSE
... i agreed to come up with a diagram for that
... second part is writing a primer on MSE so that people can
more easily understand how this works
... i don't know what the process for this is
... if we decide to take this on we might need to recruit some
for this
... i will work on the diagram for the next spec update
... question is do we want to work on a primer and if so do we
have someone willing?
adrianba: no objections to someone doing it but in the absence
of someone who wants to do this then it won't happen
acolwell: should this be a bug?
adrianba: maybe the chairs could issue a call for volunteers
glenn: this could be marked LATER too
Bug 21431 - Specify splicing behavior for text tracks
[17]https://www.w3.org/Bugs/Public/show_bug.cgi?id=21431
[17] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21431
acolwell: haven't had a lot of chance to fully digest the
discussion here
... but i think this is going to require some work
... different to audio and video because of overlapping
... and truncating is more difficult
... i will have some comments on this and areas we need to
consider
... this seems to be the most work in outstanding bugs
glenn: i would suggest an approach with a default behaviour
independent of text track usage
... semantics similar to audio should also apply
... aggressive segementation should occur and no overlaps
considered as a default
... if specific text track uses want to specify some behaviour
accounting for overlap they can
... text tracks include lots of different types of metadata and
i don't think we'll come up with one rule for all
<BobLund> +1 for Glenn's suggestion
acolwell: planned to do a run through with different webvtt
constructs
... as long as no overlapping ranges then would be okay
glenn: in ttml there are overlapping ranges so can't be ruled
out
acolwell: yeah, figured it would need to be addressed - any
help would be appreciated
glenn: i'm suggesting not trying to solve in this spec
... let the text track usage specify as necessary
acolwell: i will clarify what i think the existing behavior
should be and we can assess if this is okay for the default
glenn: that's what i'm suggesting
Bug 21536 - Specify the origin of media data provided using
Media Source Extensions
[18]https://www.w3.org/Bugs/Public/show_bug.cgi?id=21536
[18] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21536
acolwell: adrianba, you commented on this - is it resolved?
adrianba: the bug asks the question what origin should we
specify MSE data
... my answer is same origin as the page
... assign to me and i'll propose some text
out of order appends
acolwell: adrianba, you wanted to talk about out of order
append
<markw> what?!?
adrianba: when we added support for MPEG2TS, we made out of
order appends an error
... did we mean this to happen to all formats including those
that don't need it?
... this makes the programming model complex and web apps need
to keep calling abort()
<BobLund> +q
markw: surprised we made this change, out of order appends
seems like a part of our original design
... would prefer to return to the original design
BobLund: agree with adrian's sentiment
... i don't think mpeg2ts imposed a solution that resulted in
this situation
... mpeg2ts text tried to account for the timing discontinuity
... nothing in mpeg2ts byte stream spec that dictated this
solution
acolwell: problem was mpeg2ts don't really have media segment
concept
... difficult to detect discontinuity or out of order append
... introduction of append sequence made explicit that things
are adjacent
any time i want to append something not adjacent then have to
call abort
scribe: intention not to prevent out of order appending
... just indication that things are expected to be continuous
BobLund: in mpeg2 there is discontinuity indicator
<Michael_Thornburgh> +q
BobLund: for appends where it is intention that there is a
discontinuity that indicator will be set
... not obvious to me why appending with timestamps not
continuous not allowed
markw: maybe misunderstood summary at beginning
... would be better if ability to append out of order without
abort was allowed
... and case where needs to be explicit accounted for
separately
Michael_Thornburgh: apple's hls won't have discontinuity in the
TS itself - will be in the manifest
... also if you're seeking around you might not be appending
segment with discontinuity
... thought changes to api would just work in that situation
... default is the to use the timestamps
... and only in the mode where you say to ignore the timestamps
would the other behaviour happen
[19]https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source
/media-source.html#sourcebuffer-coded-frame-processing
[19] https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#sourcebuffer-coded-frame-processing
step 7
acolwell: main issue where this comes up is for cases where i
have a discontinuity frame at end of one append
... and the packet on the other side of discontinuity in next
append
... in that situation, if you can't assume one append after the
other are adjacent to each other
... then UA can't determine if this was out of order append or
not
... if you happen to append TS one packet at a time then you
can't differentiate out of order append from discontinuity
... open to other solutions for how to solve for this
... e.g. both sides of discontinuity occur in same append
... but pushback because might not know if it is in there
... if app doesn't know where the discontinuity is then have to
handle in unambiguous way
<markw> +1
adrianba: maybe something could be in the append to indicate
how to handle next data
... rather than having abort keep the next status
<markw> void appendBuffer( ArrayBuffer data, optional bool
timeContinuous );
adrianba: then if you use a format that doesn't need this you
don't need to worry about it
<markw> void appendBuffer( ArrayBuffer data, optional bool
timeContinuous = false );
acolwell: will also think about this
... over time
... any other items?
Adjournment
<markw> Thanks for chairing, Aaron
acolwell: then we're adjourned
acolwell, thanks for chairing
Summary of Action Items
[End of minutes]
-----Original Message-----
From: Paul Cotton
Sent: Tuesday, April 9, 2013 1:12 AM
To: public-html-media@w3.org
Cc: Aaron Colwell <acolwell@google.com> (acolwell@google.com); Adrian Bateman; Mark Watson; Pierre-Anthony Lemieux (pal@sandflow.com)
Subject: [VER 2] {agenda} HTML WG media telecon 2013-04-09 - MSE bug discussion
[VER 2] takes into consideration the updated MSE draft announced on April 8. I have specifically added the remaining 4 open bugs and one FIXED bug that I received a specific request for.
The HTML WG media teleconference meeting will occur on 2013-04-09 for up to 60 minutes from 15:00Z to 16:00Z.
http://timeanddate.com/s/2cjv
Tokyo midnight, Madrid/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/03/19-html-media-minutes.html
3. Review of action items
https://www.w3.org/html/wg/media/track/
None.
4. Baseline documents
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 April 8: Last updated on Apr 8:
http://lists.w3.org/Archives/Public/public-html-media/2013Apr/0038.html
5. CfC: to publish a heartbeat Media Source Extensions Working Draft
http://lists.w3.org/Archives/Public/public-html-admin/2013Mar/0037.html
WG Decision to publish is recorded at:
http://lists.w3.org/Archives/Public/public-html-admin/2013Apr/0023.html
6. F2F meeting topics
http://lists.w3.org/Archives/Public/public-html-media/2013Mar/0053.html
a) Does MSE want to request a slot for discussion at the F2F? Length of such an agenda slot?
http://www.w3.org/wiki/HTML/wg/2013-04-Agenda#Potential_Topics
Note: At a previous TF meeting some MSE participants recommended that they wanted to discuss outstanding bugs and getting into Last Call at the F2F meeting. Therefore I have already added such a request. This agenda item is thus to confirm that plan.
7. Discussion of outstanding bugs
a) Media Source Extensions bugs:
http://tinyurl.com/6pdnzej
Status as of April 8: 4 bugs (see agenda items below)
b) Bug 20760: <video> Expose statistics for tracking playback quality
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20760
c) Bug 21298 - Clarify relationship between SourceBuffer, input buffer, and tracks
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21298
d) Bug 21431 - Specify splicing behavior for text tracks
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21431
e) Bug 21536 - Specify the origin of media data provided using Media Source Extensions
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21536
f) Bug 19676 - timestampOffset accuracy
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19676
Note: I received a request from Pierre to add this FIXED bug to the agenda for further discussion.
8. 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
Received on Tuesday, 9 April 2013 16:22:22 UTC