14:38:53 <RRSAgent> RRSAgent has joined #html-media
14:38:53 <RRSAgent> logging to http://www.w3.org/2013/04/09-html-media-irc
14:38:55 <trackbot> RRSAgent, make logs public
14:38:55 <Zakim> Zakim has joined #html-media
14:38:57 <trackbot> Zakim, this will be 63342
14:38:57 <Zakim> ok, trackbot; I see HTML_WG()11:00AM scheduled to start in 22 minutes
14:38:58 <trackbot> Meeting: HTML Media Task Force Teleconference
14:38:58 <trackbot> Date: 09 April 2013
14:54:59 <Michael_Thornburgh> Michael_Thornburgh has joined #html-media
14:56:57 <pal> pal has joined #html-media
14:57:08 <glenn> glenn has joined #html-media
14:57:50 <Zakim> HTML_WG()11:00AM has now started
14:57:57 <Zakim> +Michael_Thornburgh
14:58:32 <Zakim> +glenn
14:58:58 <Zakim> +pal
14:59:00 <Bin> Bin has joined #html-media
14:59:58 <markw> markw has joined #html-media
15:00:20 <Zakim> +Bin
15:00:22 <Zakim> +Mark_Watson
15:00:37 <markw> Zakim, Mark_Watson is markw
15:00:37 <Zakim> +markw; got it
15:00:44 <Bin> present+ Bin_Hu
15:01:37 <Zakim> +[Microsoft]
15:02:17 <acolwell> acolwell has joined #html-media
15:02:34 <Zakim> +Aaron_Colwell
15:02:42 <johnsim> johnsim has joined #html-media
15:03:24 <ReimundoGarcia> ReimundoGarcia has joined #html-media
15:03:34 <Zakim> + +1.404.269.aaaa
15:04:04 <Zakim> +ReimundoGarcia
15:04:32 <jdsmith> jdsmith has joined #html-media
15:04:53 <ddorwin> ddorwin has joined #html-media
15:04:59 <BobLund> BobLund has joined #html-media
15:05:09 <Zakim> +[Microsoft.a]
15:05:24 <Zakim> +ddorwin
15:05:34 <Zakim> +BobLund
15:06:47 <markw> I guess Paul cannot make it. Anyone want t chair ?
15:07:30 <Zakim> +[Microsoft.aa]
15:07:37 <markw> (I'm on a bus - noisy - otherwise I'd volunteer)
15:07:45 <adrianba> zakim, [Microsoft.aa] is me
15:07:45 <Zakim> +adrianba; got it
15:08:03 <Zakim> -BobLund
15:08:49 <acolwell> I can chair
15:08:58 <Zakim> +BobLund
15:09:10 <markw> hooray, we can start ;-)
15:09:16 <adrianba> scribenick: adrianba
15:09:24 <adrianba> scribe: adrian bateman
15:09:29 <johnsim> zakim, who is on the call
15:09:29 <Zakim> I don't understand 'who is on the call', johnsim
15:09:30 <adrianba> chair: aaron colwell
15:09:40 <adrianba> agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Apr/0039.html
15:10:05 <adrianba> acolwell: i published an updated version of the spec with 5 bug fixes
15:10:16 <adrianba> ... mostly clarifications, nothing too huge
15:10:23 <adrianba> zakim, who is one the phone?
15:10:23 <Zakim> I don't understand your question, adrianba.
15:10:26 <adrianba> zakim, who is on the phone?
15:10:26 <Zakim> On the phone I see Michael_Thornburgh, glenn, pal, Bin, markw, [Microsoft], Aaron_Colwell, +1.404.269.aaaa, ReimundoGarcia, [Microsoft.a], ddorwin, adrianba, BobLund
15:10:35 <adrianba> TOPIC: CfC: to publish a heartbeat Media Source Extensions Working Draft
15:10:50 <adrianba> WG Decision: http://lists.w3.org/Archives/Public/public-html-admin/2013Apr/0023.html
15:11:21 <adrianba> adrianba: think we need to work with Robin or Mike to get this published
15:11:28 <adrianba> TOPIC: F2F meeting topics
15:11:39 <adrianba> acolwell: thought we could talk about what we need to do to get to last call
15:11:55 <adrianba> ... sems like the bug count is pretty low
15:12:00 <adrianba> s/sems/seems/
15:12:09 <adrianba> q+
15:12:19 <adrianba> acolwell: do we want the slot at the face-to-face?
15:12:29 <pal> q+
15:12:36 <pal> q-
15:13:49 <adrianba> adrianba: i'd like to see us make progress towards LC
15:13:58 <adrianba> ... perhaps we can give notice to the WG that we're getting close
15:14:14 <adrianba> pal: would like to do this on the 23rd at the f2f
15:14:22 <adrianba> q+
15:14:40 <adrianba> acolwell: think we can put in a request for the 23rd but it might not be decided before everyone is in the room
15:15:23 <adrianba> adrianba: does anyone on the call object to requesting 23rd? perhaps we could add this to the wiki
15:15:36 <adrianba> acolwell: not hearing any objections
15:15:56 <adrianba> ack adr
15:16:05 <adrianba> acolwell: anything else about the f2f meeting?
15:16:14 <adrianba> TOPIC: Discussion of outstanding bugs
15:16:16 <adrianba> q+
15:17:00 <adrianba> adrianba: would like to discuss out of order appends in this section
15:17:04 <adrianba> ack adr
15:17:13 <adrianba> acolwell: let's address that after the others
15:17:14 <markw> q+
15:17:27 <adrianba> Bug 20760: <video> Expose statistics for tracking playback quality
15:17:33 <adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20760
15:17:54 <adrianba> markw: discussion has a tendency to grow out of control - is a real problem related to adaptive streaming
15:18:08 <adrianba> ... for some devices that can't play high quality videos
15:18:24 <adrianba> [lost some of the comment at the end]
15:18:25 <adrianba> q+
15:18:31 <adrianba> ack markw
15:20:01 <adrianba> adrianba: two issues - are the metrics the correct ones and where should it be specified
15:20:04 <adrianba> ack adr
15:20:28 <adrianba> ... on the first, i think i'd like to see more discussion on the detail of the proposal
15:21:02 <adrianba> ... 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
15:21:40 <adrianba> acolwell: my main concern is that there currently isn't a mechanism for recording statistics on media element
15:21:43 <markw> q+
15:21:52 <adrianba> ... and if the HTML WG decides to specify that then there might be two
15:21:54 <adrianba> q+
15:22:12 <adrianba> ... i'd like to get consensus for how to expose this and then decide where to put it
15:22:35 <adrianba> markw: i think we probably should have a target that there is something comprehensive on the element
15:22:47 <adrianba> ... the discussion is quite a long way from going somewhere in the WG
15:23:01 <adrianba> ... don't think there is much chance of this going forward quickly
15:23:27 <adrianba> ... think this is important for deployments of MSE and we need this implementation experience to drive the spec forward
15:23:39 <adrianba> ... would like to see something in MSE with the understanding it might be replaced in future
15:24:35 <adrianba> adrianba: we are the HTML WG and the full WG needs to agree with the output from the TF'
15:24:41 <adrianba> s/TF'TF/
15:24:45 <adrianba> s/TF'/TF/
15:24:55 <adrianba> acolwell: next step is to solicit comments from the WG?
15:24:59 <adrianba> adrianba: yes
15:25:16 <adrianba> Bug 19676 - timestampOffset accuracy
15:25:23 <adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19676
15:25:24 <acolwell> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19676
15:25:32 <adrianba> acolwell: let's go to this one since pal wants to talk to it
15:25:46 <adrianba> pal: subject of lengthy discussion
15:25:59 <adrianba> ... in the last comment, editor suggests additional implementation experience is necessary
15:26:16 <adrianba> ... my first suggestion is that in that case the bug should be kept open and not closed
15:26:19 <adrianba> q?
15:26:21 <adrianba> ack ma
15:26:23 <adrianba> ack ad
15:26:36 <adrianba> acolwell: i could mark as resolved later instead of resolved fixed
15:26:43 <adrianba> ... that's how we marked some other things
15:26:49 <adrianba> ... trying to drive the bug count to zero
15:26:54 <adrianba> ... to get to LC
15:26:58 <glenn> q+
15:27:13 <adrianba> pal: sympathise with the desire to mark as resolved
15:27:16 <adrianba> q+
15:27:19 <adrianba> ... but don'
15:27:28 <markw> q-
15:27:33 <adrianba> s/don'/don't see how this is done/
15:27:35 <adrianba> ack gl
15:27:46 <adrianba> glenn: prefer to resolve as fixed and open a new bug in future
15:27:52 <pal> q+
15:27:53 <adrianba> ... to vague to say needs implementation experience
15:28:03 <adrianba> ... that's the purpose of CR phase
15:28:12 <adrianba> ack adr
15:28:18 <adrianba> adrianba: agree with glenn
15:28:27 <adrianba> ack pal
15:28:54 <adrianba> pal: glenn and adrian, don't believe this is a subjective question, very much mathematical
15:29:03 <adrianba> ... spec says as accurate as possible
15:29:05 <adrianba> q+
15:29:27 <adrianba> ... bug was opened because of accuracy of timestamp
15:29:32 <acolwell> q+
15:29:46 <adrianba> ... comfortable with seeing how implementations work around that but uncomfortable saying this is resolved
15:30:13 <adrianba> 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
15:30:31 <adrianba> ... problem is lack of specific change to make other than keeping open
15:30:45 <adrianba> pal: very early in the thread there is a very specific suggestion for how to resolve
15:32:15 <adrianba> ack adr
15:32:31 <adrianba> adrianba: if there is a concrete text alternative proposal then i think you should reopen the bug
15:32:40 <adrianba> ... there is a process within the WG to resolve the situation when
15:32:48 <adrianba> ... there is not a clear consensus for what the spec should say
15:32:58 <adrianba> ... if we have differing proposals the chairs will run this process
15:33:04 <adrianba> ... to decide what the spec should say
15:33:12 <adrianba> ack acolwell
15:33:44 <adrianba> acolwell: i believe i addressed the suggestion for rationals in comment 9
15:33:45 <adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19676#c9
15:34:05 <adrianba> acolwell: using a single rational doesn't solve the problem because of if you mix content of different frame rates
15:34:19 <markw> markw has joined #html-media
15:34:19 <adrianba> ... i believe the spec text provides sufficient mechanism to be close enough
15:34:38 <adrianba> ... and avoid the problem of if a frame is slightly after the last frame it would get removed
15:34:58 <adrianba> ... i think the time differences because of using the double would not be perceivable by the user
15:35:10 <adrianba> ... that's why i think implementation experience is needed
15:35:20 <adrianba> ... all implementations will likely round to some precision
15:35:21 <pal> q+
15:35:38 <adrianba> ... and it will be too difficult to specify precisely how different implementations will do this rounding
15:35:58 <adrianba> pal: i agree, fine with waiting for implementations
15:36:27 <adrianba> ... what i wanted to bring up was marking a bug as resolved when it looks like additional experience is needed doesn't feel right
15:36:40 <adrianba> acolwell: as i say, i could resolve as later
15:37:02 <adrianba> pal: this would help look back at the end at the bugs we weren't sure of
15:37:06 <adrianba> ... sounds reasonable to me
15:37:13 <adrianba> acolwell: okay with everyone else?
15:37:26 <adrianba> ... does anyone object to resolving this as LATER
15:37:32 <adrianba> adrianba: no objection
15:37:48 <adrianba> acolwell: not hearing anything - just updated the bug, now RESOLVED LATER
15:38:06 <adrianba> Bug 21298 - Clarify relationship between SourceBuffer, input buffer, and tracks
15:38:11 <adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21298
15:38:20 <adrianba> acolwell: two parts to this
15:38:33 <adrianba> ... one is a request for a diagram showing how appended data moves through MSE
15:38:40 <adrianba> ... i agreed to come up with a diagram for that
15:38:58 <adrianba> ... second part is writing a primer on MSE so that people can more easily understand how this works
15:39:07 <adrianba> ... i don't know what the process for this is
15:39:07 <adrianba> q?
15:39:09 <adrianba> ack pal
15:39:22 <adrianba> acolwell: if we decide to take this on we might need to recruit some for this
15:39:29 <pal> q-
15:39:48 <adrianba> acolwell: i will work on the diagram for the next spec update
15:40:02 <adrianba> ... question is do we want to work on a primer and if so do we have someone willing?
15:40:05 <adrianba> q+
15:40:43 <adrianba> adrianba: no objections to someone doing it but in the absence of someone who wants to do this then it won't happen
15:41:16 <adrianba> acolwell: should this be a bug?
15:41:28 <adrianba> adrianba: maybe the chairs could issue a call for volunteers
15:41:43 <adrianba> glenn: this could be marked LATER too
15:42:01 <adrianba> Bug 21431 - Specify splicing behavior for text tracks
15:42:08 <adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21431
15:42:21 <adrianba> acolwell: haven't had a lot of chance to fully digest the discussion here
15:42:29 <adrianba> ... but i think this is going to require some work
15:42:38 <adrianba> ... different to audio and video because of overlapping
15:42:46 <adrianba> ... and truncating is more difficult
15:42:55 <adrianba> ... i will have some comments on this and areas we need to consider
15:43:06 <adrianba> ... this seems to be the most work in outstanding bugs
15:43:21 <adrianba> glenn: i would suggest an approach with a default behaviour independent of text track usage
15:43:31 <adrianba> ... semantics similar to audio should also apply
15:43:45 <adrianba> ... aggressive segementation should occur and no overlaps considered as a default
15:44:00 <adrianba> ... if specific text track uses want to specify some behaviour accounting for overlap they can
15:44:21 <adrianba> ... text tracks include lots of different types of metadata and i don't think we'll come up with one rule for all
15:44:29 <BobLund> +1 for Glenn's suggestion
15:44:33 <adrianba> acolwell: planned to do a run through with different webvtt constructs
15:44:46 <adrianba> ... as long as no overlapping ranges then would be okay
15:44:59 <adrianba> glenn: in ttml there are overlapping ranges so can't be ruled out
15:45:17 <adrianba> acolwell: yeah, figured it would need to be addressed - any help would be appreciated
15:45:27 <adrianba> glenn: i'm suggesting not trying to solve in this spec
15:45:40 <adrianba> ... let the text track usage specify as necessary
15:45:59 <adrianba> acolwell: i will clarify what i think the existing behavior should be and we can assess if this is okay for the default
15:46:09 <adrianba> glenn: that's what i'm suggesting
15:46:16 <adrianba> q?
15:46:20 <adrianba> q-
15:46:29 <adrianba> Bug 21536 - Specify the origin of media data provided using Media Source Extensions
15:46:36 <adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21536
15:46:58 <adrianba> acolwell: adrianba, you commented on this - is it resolved?
15:47:11 <markw> q+
15:48:05 <markw> q-
15:48:58 <adrianba> adrianba: the bug asks the question what origin should we specify MSE data
15:49:08 <adrianba> ... my answer is same origin as the page
15:49:13 <adrianba> ... assign to me and i'll propose some text
15:49:24 <adrianba> acolwell: adrianba, you wanted to talk about out of order append
15:50:21 <markw> what?!?
15:51:26 <markw> Q+
15:52:47 <adrianba> adrianba: when we added support for MPEG2TS, we made out of order appends an error
15:53:00 <adrianba> ... did we mean this to happen to all formats including those that don't need it?
15:53:18 <adrianba> ... this makes the programming model complex and web apps need to keep calling abort()
15:53:32 <BobLund> +q
15:53:36 <adrianba> markw: surprised we made this change, out of order appends seems like a part of our original design
15:53:43 <adrianba> ack ma
15:53:53 <adrianba> markw: would prefer to return to the original design
15:54:04 <adrianba> BobLund: agree with adrian's sentiment
15:54:19 <adrianba> ... i don't think mpeg2ts imposed a solution that resulted in this situation
15:54:37 <adrianba> ... mpeg2ts text tried to account for the timing discontinuity
15:54:50 <adrianba> ... nothing in mpeg2ts byte stream spec that dictated this solution
15:54:52 <adrianba> ack bob
15:55:08 <adrianba> acolwell: problem was mpeg2ts don't really have media segment concept
15:55:20 <adrianba> ... difficult to detect discontinuity or out of order append
15:55:38 <adrianba> ... introduction of append sequence made explicit that things are adjacent
15:55:49 <adrianba> any time i want to append something not adjacent then have to call abort
15:56:01 <adrianba> ... intention not to prevent out of order appending
15:56:14 <markw> q+
15:56:20 <adrianba> ... just indication that things are expected to be continuous
15:56:33 <adrianba> BobLund: in mpeg2 there is discontinuity indicator
15:56:46 <Michael_Thornburgh> +q
15:56:48 <adrianba> ... for appends where it is intention that there is a discontinuity that indicator will be set
15:57:05 <adrianba> ... not obvious to me why appending with timestamps not continuous not allowed
15:57:18 <adrianba> markw: maybe misunderstood summary at beginning
15:57:37 <adrianba> ... would be better if ability to append out of order without abort was allowed
15:57:54 <adrianba> ... and case where needs to be explicit accounted for separately
15:57:57 <adrianba> ack ma
15:58:03 <adrianba> ack mi
15:58:27 <adrianba> Michael_Thornburgh: apple's hls won't have discontinuity in the TS itself - will be in the manifest
15:58:41 <adrianba> ... also if you're seeking around you might not be appending segment with discontinuity
15:58:52 <adrianba> ... thought changes to api would just work in that situation
15:59:08 <adrianba> ... default is the to use the timestamps
15:59:27 <adrianba> ... and only in the mode where you say to ignore the timestamps would the other behaviour happen
15:59:47 <adrianba> q+
16:00:15 <adrianba> https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#sourcebuffer-coded-frame-processing
16:00:19 <adrianba> step 7
16:00:36 <adrianba> q-
16:00:36 <Zakim> -Bin
16:00:58 <adrianba> acolwell: main issue where this comes up is for cases where i have a discontinuity frame at end of one append
16:01:10 <adrianba> ... and the packet on the other side of discontinuity in next append
16:01:26 <adrianba> ... in that situation, if you can't assume one append after the other are adjacent to each other
16:01:38 <adrianba> ... then UA can't determine if this was out of order append or not
16:02:00 <adrianba> ... if you happen to append TS one packet at a time then you can't differentiate out of order append from discontinuity
16:02:11 <adrianba> ... open to other solutions for how to solve for this
16:02:24 <adrianba> ... e.g. both sides of discontinuity occur in same append
16:02:33 <adrianba> ... but pushback because might not know if it is in there
16:02:37 <adrianba> q+
16:02:57 <adrianba> ... if app doesn't know where the discontinuity is then have to handle in unambiguous way
16:04:23 <markw> +1
16:04:29 <adrianba> adrianba: maybe something could be in the append to indicate how to handle next data
16:04:47 <adrianba> ... rather than having abort keep the next status
16:04:50 <markw> void appendBuffer( ArrayBuffer data, optional bool timeContinuous );
16:05:03 <adrianba> ... then if you use a format that doesn't need this you don't need to worry about it
16:05:08 <markw> void appendBuffer( ArrayBuffer data, optional bool timeContinuous = false );
16:05:08 <adrianba> acolwell: will also think about this
16:05:23 <adrianba> acolwell: over time
16:05:28 <adrianba> ... any other items?
16:05:44 <adrianba> TOPIC: Adjournment
16:05:55 <Zakim> -BobLund
16:05:56 <markw> Thanks for chairing, Aaron
16:05:56 <adrianba> acolwell: then we're adjourned
16:05:58 <Zakim> -ReimundoGarcia
16:05:59 <Zakim> -ddorwin
16:05:59 <Zakim> -[Microsoft]
16:06:00 <Zakim> -Michael_Thornburgh
16:06:03 <Zakim> -glenn
16:06:05 <Zakim> -adrianba
16:06:08 <Zakim> -Aaron_Colwell
16:06:10 <adrianba> zakim, bye
16:06:10 <Zakim> leaving.  As of this point the attendees were Michael_Thornburgh, glenn, pal, Bin, markw, [Microsoft], Aaron_Colwell, +1.404.269.aaaa, ReimundoGarcia, ddorwin, BobLund, adrianba
16:06:10 <Zakim> Zakim has left #html-media
16:06:15 <adrianba> rrsagent, make minutes
16:06:15 <RRSAgent> I have made the request to generate http://www.w3.org/2013/04/09-html-media-minutes.html adrianba
16:06:18 <adrianba> rrsagent, make logs public
16:06:29 <adrianba> acolwell, thanks for chairing
16:07:38 <adrianba> i/adrianba, you wanted to talk/TOPIC: out of order appends/
16:07:43 <adrianba> rrsagent, make minutes
16:07:43 <RRSAgent> I have made the request to generate http://www.w3.org/2013/04/09-html-media-minutes.html adrianba
16:23:32 <acolwell> acolwell has joined #html-media