See also: IRC log
<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
WG Decision: 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
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?
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
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19676
<acolwell> 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
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
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
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
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
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
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?
<markw> Thanks for chairing, Aaron
acolwell: then we're adjourned
acolwell, thanks for chairing
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) Succeeded: s/sems/seems/ FAILED: s/TF'TF// Succeeded: s/TF'/TF/ Succeeded: s/don'/don't see how this is done/ Succeeded: i/adrianba, you wanted to talk/TOPIC: out of order appends Found ScribeNick: adrianba Found Scribe: adrian bateman Default Present: Michael_Thornburgh, glenn, pal, Bin, markw, [Microsoft], Aaron_Colwell, +1.404.269.aaaa, ReimundoGarcia, ddorwin, BobLund, adrianba Present: Michael_Thornburgh glenn pal Bin markw [Microsoft] Aaron_Colwell +1.404.269.aaaa ReimundoGarcia ddorwin BobLund adrianba Bin_Hu Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Apr/0039.html Found Date: 09 Apr 2013 Guessing minutes URL: http://www.w3.org/2013/04/09-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]