14:43:45 <RRSAgent> RRSAgent has joined #mediacap
14:43:45 <RRSAgent> logging to http://www.w3.org/2015/05/26-mediacap-irc
14:43:47 <trackbot> RRSAgent, make logs public
14:43:47 <Zakim> Zakim has joined #mediacap
14:43:49 <trackbot> Zakim, this will be MCAP
14:43:49 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
14:43:50 <trackbot> Meeting: Media Capture Task Force Teleconference
14:43:50 <trackbot> Date: 26 May 2015
14:51:43 <stefanh> stefanh has joined #mediacap
14:53:53 <hta1> hta1 has joined #mediacap
14:55:57 <Shijun> Shijun has joined #mediacap
14:58:59 <burn> burn has joined #mediacap
15:00:25 <dom> Present+ Dan_Burnett, StefanH, HTA, Dom, Giri
15:00:52 <dom> Present+ Shijun
15:01:40 <dom> Present+ Adam_Roach
15:01:55 <Guest90> Guest90 has joined #mediacap
15:02:32 <adambe> yes
15:02:36 <dom> Present+ AdamB
15:02:41 <Guest90> Guest90 has left #mediacap
15:02:51 <jib> jib has joined #mediacap
15:03:55 <burn> zakim, I am Dan_Burnett
15:03:55 <Zakim> sorry, burn, I do not see a party named 'Dan_Burnett'
15:05:55 <hta> zakim, who is on?
15:05:55 <Zakim> I don't understand your question, hta.
15:06:01 <hta> zakim, who is here?
15:06:01 <Zakim> sorry, hta, I don't know what conference this is
15:06:02 <dom> Chair: stefanh, hta
15:06:03 <Zakim> On IRC I see jib, burn, Shijun, hta, stefanh, Zakim, RRSAgent, adambe, dom, richt, timeless, slightlyoff, adamR|mtg, derf, Josh_Soref, trackbot
15:06:15 <dom> Topic: Agenda bashing
15:06:21 <dom> Scribe: Dom
15:06:42 <dom> Stefan: any request for change to the agenda?
15:06:44 <dom> [none]
15:06:52 <dom> Topic: Walk-through proposed responses
15:07:23 <dom> -> https://lists.w3.org/Archives/Public/public-media-capture/2015May/att-0075/DispositionofComments-LC1forMediaCaptureandStreams.pdf Proposed responses to last call comments
15:08:19 <jib> me
15:08:25 <dom> Present+ Jan-Ivar
15:08:44 <dom> Topic: LC­3013 ­ related streams such as captions or subtitles
15:09:00 <mt> mt has joined #mediacap
15:09:13 <dom> HTA:  I propose that we start by checking whether we are in agreement or not, and file for later things on which there isn't agreement
15:09:28 <dom> ... on this particular item, I suggest we mark it as something we might look at a later time, but "not now"
15:09:36 <dom> [no disagreement expressed]
15:09:46 <dom> Topic: LC­3009 ­ asking about defining a video filter chain
15:10:00 <dom> HTA: proposed same response: could think about it, but not yet
15:10:09 <dom> [no disagreement expressed]
15:10:18 <dom> Topic: LC­3018 ­ please use [Exposed]
15:10:40 <dom> HTA: we discussed this, and we will document it
15:11:05 <dom> AdamB: we've prepared a PR for this, and AnneVK +1'd it
15:11:17 <dom> JIB: there is ongoing discussion of data channel in workers though
15:11:21 <dom> hta: that's a different spec
15:11:47 <mt> oh, so we're really going through this one by one by one
15:11:53 <dom> HTA: I have a question about how an interfance that is exposed in a worker but references an interface that isn't, how does that work
15:11:58 <dom> ... but that's for WebRTC
15:12:07 <dom> Topic: LC­3020 ­ asking for video+audio (muxed) as a new track type
15:12:15 <vivien> vivien has joined #mediacap
15:12:44 <dom> Stefan: my proposed response is that we haven't seen use cases that mandate muxed track, and the current set of APIs should be able to deal with that
15:12:54 <dom> ... proposed no change in response to the comment
15:13:06 <dom> [no disagreement expressed]
15:13:08 <vivien> vivien has changed the topic to: Media Cap TF call on gUM LC comments: https://lists.w3.org/Archives/Public/public-media-capture/2015May/0075.html
15:13:16 <dom> Topic: LC­3026 ­ internationalization of device “label”
15:13:24 <dom> HTA: this is a difficult issue
15:13:43 <dom> ... one reason being that the labels we pick up come from systems, we can't translate them on the fly
15:13:55 <dom> ... I think we need to ask advice from I18N
15:14:11 <dom> ... we will otherwise assume the language attribute comes from navigator.language
15:14:26 <dom> ... I don't think it's settled yet; we need advice from I18N experts
15:14:42 <dom> @@@: I agree given how different labels we get from devices
15:14:48 <dom> Stefan: so this requires more work
15:14:54 <dom> Topic: LC­3021 ­ capabilities registration
15:15:18 <dom> DanB: where we use capabilities, we don't have the definitions since they are in the IANA registry
15:15:38 <dom> ... assuming we keep the current structure of the document, my suggestion is to add text with link to the IANA registry
15:16:09 <dom> ... and then, since the specific properties are defined the same doc, we will also add informative references to these
15:16:28 <dom> Stefan: maybe this needs to be parked until we look at the IANA registry topic
15:16:38 <dom> Topic: LC­3022 ­ latency constraint
15:16:47 <dom> Stefan: Peter looked at this
15:17:02 <dom> ... but he's not on the call; HTA, you've been involved too
15:17:17 <dom> HTA: my impression from the list is that this is a reasonable thing to do and that we should do this and no more
15:17:42 <dom> Shijun: what should be the behavior if the latency is set to a very low value close to zero?
15:17:53 <dom> hta: for the constraint or the state?
15:17:58 <dom> shijun: the constraint
15:18:22 <dom> hta: if you set the max of the constraint to a very low value and it is not satisfiable, then the constraint will fail
15:18:37 <dom> shijun: is this audio only? or does it apply to video as well?
15:18:46 <dom> hta: I suspect we could have it for both
15:19:25 <dom> ... they would probably be different between audio and video
15:20:00 <dom> shijun: should we have some guidance in the spec on dealing with ridiculously low values?
15:20:15 <dom> DanB: the behavior for extreme values is the same for all constraints
15:20:27 <dom> shijun: ok, that's right
15:20:35 <dom> jib: would it be useful to add an example?
15:20:46 <dom> stefan: we have a proposal to add a constraint
15:21:02 <dom> ... but there seems to be a need for more work
15:21:21 <dom> DanB: including on the video piece
15:21:36 <dom> Stefan: so consensus to adopt that constraint, but more work is needed?
15:21:53 <dom> DanB: "more work" is not sufficient for a LC resolution :)
15:22:30 <dom> Shijun: in Microsoft, we will want to give as low a latency as possible in general
15:22:49 <dom> ... this max latency is probably not as useful
15:23:01 <dom> ... at the platform level, we're doing our best to not add any delay
15:23:18 <dom> ... this may be useful in other platforms, but I would like to hear from other implementors on how common that is
15:23:41 <dom> HTA: the original request came from someone dealing with a trade off between battery life and latency
15:24:03 <dom> shijun: is that from an app developer or a device dev?
15:24:12 <dom> HTA: he works for google in speech recognition
15:24:39 <dom> DanB: I come from that background too, and there are a number of cases where low latency is also critical in this space
15:24:56 <dom> ... in any case, this is a valuable constraint for speech recognition
15:25:16 <dom> ... for a distributed band, this is also critically important
15:26:06 <dom> HTA: on Android, we currently have two paths in the audio subsystem with different latency characteristics, used for different purposes
15:26:42 <dom> DanB: re speech recognition, if there is too long of a delay in responses, users tend to react with spectactularly bad behavior
15:27:01 <dom> JIB: I understand the original request to enable "OK Google" with low battery consumption
15:27:15 <dom> Stefan: OK, this needs more work
15:27:29 <dom> hta: there is consensus on adding the constraint, but more work needed on example and explanation
15:27:36 <dom> Topic: LC­3015 ­ TrackEvent not nullable
15:28:15 <dom> https://github.com/w3c/mediacapture-main/pull/169
15:28:25 <dom> Stefan: the change has been made
15:28:44 <dom> AdamB: we require the "track" property now
15:28:55 <dom> ... using the new WebIDL "required" keyword
15:29:09 <dom> ... which then enables non-optional dictionaries
15:29:34 <dom> [no disagreement expressed]
15:29:41 <dom> Topic: LC­3016 ­ Direct assignment to media elements
15:30:02 <dom> Stefan: the gUM LC doc defined the integration in HTML Media Element with srcObject
15:30:07 <dom> ... but that is now defined in HTML5.1
15:30:21 <dom> ... we have a pull request that refers to HTML5.1 instead of defining it on our own
15:30:43 <dom> ... there is still some unclear pieces in HTML5.1 about assigning id/kind/label, so we have kept that in our document for now
15:31:10 <dom> DanB: fine with that — only need to fix the title of the spec in the response
15:31:13 <dom> [no disagreement expressed]
15:31:19 <dom> Topic: LC­3017 MediaStreamError
15:31:49 <dom> DanB: this is still under discussion (not clear yet whether it is difficult)
15:32:02 <dom> ... good discussion is happening; jib and domenic had a good back and forth
15:32:16 <dom> ... which led to a proposal I sent to the list
15:32:31 <dom> ... we don't have a resolution yet, but it's in progress
15:32:39 <dom> Topic: LC­3027 Internationalization of “message”
15:32:51 <dom> hta: another tricky question
15:33:14 <dom> ... I tried to look at how Ecmascript deals with internationalizing errors, but couldn't find any clue
15:33:29 <dom> ... we should probably clarify that the message property is used for debugging, not to display to users
15:33:45 <dom> ... if there is a need for I18N, it should be dealt with at the Ecmascript level
15:33:53 <dom> ... suggest no change
15:33:56 <dom> JIB: I agree
15:34:29 <dom> DanB: clearly this needs to be solved at a different level than ours; it would be confusing for us to try and solve this
15:35:02 <dom> Toipc: LC­3025 onaddtrack
15:35:33 <dom> JIB: I've always interpreted onaddtrack and onremovetrack as "onremoteaddtrack" and "onremoteremotetrack", is that correct?
15:35:49 <dom> adambe: it would be more "onunexpectedaddtrack" and "onunexpectedremovetrack"
15:36:00 <dom> ... any track event generated by the UA would fit this, not just remote
15:36:32 <dom> hta: e.g. if you produce a stream from a video track, and you change the stream, it might come with a different number of tracks
15:36:47 <dom> adambe: I think the track would end there
15:37:26 <dom> ... but if someone is sending you a track and add it to a stream, this should notify the stream of a new track
15:37:59 <dom> JIB: isn't the problem that this underspecified at the moment?
15:38:19 <dom> hta: the spec doesn't specify under which conditions the addtrack event fires
15:38:53 <dom> ... media stream from video might be one such spec
15:39:19 <dom> adambe: should we set guidance on how specs should determine when the addtrack event fire?
15:39:52 <dom> ... anyway, right now, the main case is remote addtrack (?)
15:40:24 <dom> ... I don't think we should notify local track changes
15:40:59 <dom> hta: so we adopt the decision of not firing on local track changes, but we need to write up guidance for other specs
15:41:51 <dom> adambe: should we add some text in the spec explaining that no feature in gUM will trigger these events, but that other specs will define that
15:41:56 <dom> hta: we should do that
15:42:03 <dom> danb: so we're making a change
15:42:22 <dom> adambe: should we reference webrtc 1.0 as an example?
15:42:24 <dom> hta: yes
15:42:33 <dom> DanB: we need an updated proposal for that one
15:42:38 <dom> stefan: agree
15:42:45 <dom> Topic: LC­3010 enumerateDevices() should be getAll()
15:42:58 <dom> Present+ Martin
15:43:10 <dom> HTA: I saw no compelling reason for change; so suggest no change
15:43:14 <dom> [no disagreement expresseð]
15:43:23 <dom> Topic: LC­3023 More information about devices available before using getUserMedia
15:43:28 <dom> Stefan: no proposal yet
15:43:32 <dom> HTA: currently under discussion
15:43:47 <dom> ... it goes to the broader question of how much information to make available and when
15:44:17 <dom> ... The requester agreed on mail that if he had all information on the device available in enumerateDevices(), his use cases would be satisified
15:44:25 <dom> ... but brings a lot of fingerprinting surface
15:44:49 <dom> Shinjun: we don't have a complete proposal; it is an interesting topic
15:44:57 <dom> DanB: we have discussed this before quite extensively
15:45:18 <mt> https://github.com/w3ctag/spec-reviews/blob/master/2015/05/fingerprint.md
15:45:24 <mt> q?
15:45:36 <dom> ... before we make the decision to reinvestigate this, I would like to see what new information justify reevaluating it
15:45:54 <dom> hta: if we want to keep away from "drive-by" web, we need a permission gate
15:46:08 <dom> mt: note that the TAG recent finding is interesting input on that aspect
15:46:36 <dom> shijun: this is more about audio output rather than input devices, right?
15:46:48 <dom> q+ to mention this relates to audio output devices api re permissioning
15:46:57 <dom> hta: right
15:47:21 <dom> shijun: one way to do that is to have some extension point in the future where that can be extended
15:49:03 <dom> dom: the TAG statement on fingerprinting and the audio device output api are sufficient information for me
15:50:25 <dom> Topic: LC­3024 Removing the constraint registry
15:51:11 <dom> DanB: my proposal is that no new information was provided to justify reopening
15:51:30 <dom> martin: note that I never was involved in these discussions
15:52:03 <dom> DanB: my intention was to say that this is a new request, and there doesn't seem to be new information
15:53:54 <dom> ... so I don't feel this is like we should re-discuss it; I don't feel it is a last call comment per se
15:54:23 <dom> Martin: there is a lot of changes in the way W3C has approached its specifications maintenances in the past 2 years with emphasis on living document and other aspects of this
15:54:29 <dom> ... I don't know if these have been considered
15:54:38 <stefanh> q?
15:54:50 <dom> hta: they have been considered, but it is far from clear that the W3C has moved to a living document working model
15:55:02 <dom> martin: that's true; there doesn't seem to be a single W3C working model
15:55:03 <dom> q-
15:55:17 <dom> q+
15:55:54 <dom> jib: now might be a good time to assess whether the "registration" feature is something anyone will use
15:57:01 <dom> hta: are you suggesting we should treat extensibility as a feature and review it when going to CR?
15:57:26 <dom> ... see if anybody uses it?
15:57:28 <dom> martin: I like this
15:57:57 <dom> dom: FWIW, my recollection of the consensus was that we didn't have enough experience with extensibility to settle on a specific mechanism
15:58:18 <dom> ... but that consensus didn't seem to have taken root in the spec
15:59:03 <dom> danb: I defer to the chairs to assess whether there was enough consensus or not on the registry; interesting idea of looking at it as a feature
15:59:13 <dom> ... just removing it is not enough though
15:59:50 <dom> stefan: there was some agreement to look at it as a feature
16:00:17 <dom> danb: for features that you might have trouble getting implementation of, you mark it as "at risk" in CR
16:00:32 <dom> ... removing delay to go to PR if you remove it
16:02:02 <dom> dom: note that delay is less important in the new process
16:02:17 <dom> danb: still, this would create an additional CR round
16:04:18 <dom> dom: not sure we need this for this spec since this is procedural
16:04:30 <dom> danb: you need this for conformance statement
16:04:42 <dom> martin: but does conformance to a moving target — does that make sense?
16:04:58 <dom> hta: a conformance statement would say I recognize these values
16:05:10 <dom> martin: but that's just conformance to the spec
16:05:37 <dom> danb: that question would similarly applies to any IETF spec applying the same procedure
16:06:01 <dom> martin: I think that procedure makes sense in some contexts; I don't think it makes sense here, in this implementation context
16:06:19 <dom> danb: others have made that comparison, so I wanted to voice it
16:06:33 <dom> ... but I don't think we should have that discussion here and now
16:06:41 <dom> ... clearly, this needs more discussion
16:06:51 <dom> stefan: agreed
16:07:05 <dom> Topic: LC­3012 Active attribute description
16:07:14 <dom> -> https://github.com/w3c/mediacapture-main/pull/168 PR 168
16:07:34 <dom> AdamB: there was a confusion between the concept of active/inactive, and the attribute
16:07:45 <dom> ... the piece of text with that error is actually not needed at all
16:08:17 <dom> ... the active state in a mediastream depends on its tracks
16:08:26 <dom> [no disagreement expressed]
16:08:33 <dom> Topic: LC­3011 addTrack() description is not tamper free
16:08:41 <dom> -> https://github.com/w3c/mediacapture-main/pull/167 PR 167
16:09:07 <dom> AdamB: the problem there was that we referred to a algorithms as defined in the public API, e.g. for clone a stream
16:09:39 <dom> ... the problem of doing so is that if someone overwrite the track clone method, we don't want that changed behavior to be reflected in the mediastream
16:09:57 <dom> ... so we need to use private algorithms that are referenced by the public API and other points where needed
16:10:01 <dom> [no disagreement expressed]
16:10:16 <dom> Topic: LC­3014 Life cycle and media flow (remove “detached”)
16:10:30 <dom> AdamB: we had 2 concepts for stopping a track
16:10:41 <dom> ... "stopping" and "detaching" a track source
16:10:52 <dom> ... this was unnecessarily complicated, and it was suggested we should use just one
16:11:06 <jib> jib has joined #mediacap
16:11:06 <dom> ... sounds like the right thing to do
16:11:15 <dom> [no disagreement expressed]
16:11:27 <dom> Topic: LC­3019 IDL errors
16:11:38 <dom> DanB: this is linked the constrainable pattern template
16:11:45 <dom> ... WebIDL doesn't allow us to express this
16:12:07 <dom> ... this creates failure if you try to check the document in the webidl checker
16:12:31 <dom> ... my proposal is to describe in a little more details these limitations
16:13:00 <dom> ... it's worth noting that MediaStreamError will be also result in non-WebIDL complete definitions
16:13:25 <dom> ... we'll need ES6 style language, and thus there will no IDL for them
16:14:01 <dom> Dom: is there any spec that is going to re-use ConstrainablePattern?
16:14:11 <dom> AdamB: MediaRecorder I think?
16:14:26 <dom> Stefan: Image Capture too I think, not sure
16:14:45 <dom> [no disagreement expressed]
16:15:26 <dom> JIB: there were specific complaints about capabilities and settings; we could use a quick fix with empty dictionaries as we did for constraints
16:15:34 <dom> hta: that's a work around we could choose to apply or not
16:15:50 <dom> danb: I'm not rejecting that; let's talk about a little bit
16:16:28 <dom> Topic: Conclusions
16:16:35 <dom> HTA: I'll send my summary of our decisions
16:16:44 <dom> Shijun: I had a comment on the latency constraint
16:17:09 <dom> ... I wonder if it would be better to define it as a boolean value rather than a double
16:17:25 <dom> ... the latency might be dynamic depending on the system load
16:17:44 <dom> ... if the purpose is power-saving, lower resolution values might be better
16:17:49 <dom> hta: this was discussed on the list
16:18:06 <dom> ... the conclusion was that there are so many different use cases that using boolean to separate this was probably unwise
16:18:15 <dom> shijun: I didn't notice that in the mailing list
16:18:31 <dom> hta: there is a question about whether the latency is operational or a guarantee
16:18:41 <dom> ... it's hard to guarantee a latency due to system load as you mention
16:18:46 <dom> ... that's worth discussing more on the list
16:18:58 <dom> danb: "how fuzzy are the values allowed to be"
16:19:32 <dom> shijun: also the distinction between initial static latency and running latency
16:20:33 <dom> hta: I suspect many implementations will use a threshold to determine which codepath to use
16:21:08 <dom> shijun: testing will be headache; you'll have to trust the platform
16:21:46 <dom> hta: the chairs will take on processing the ones we think we have resolved and pass them on to the proposers and see if they're happy
16:21:57 <dom> ... thanks all for coming
16:22:10 <dom> RRSAgent, draft minutes
16:22:10 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/26-mediacap-minutes.html dom
16:23:36 <dom> s/<dom> ->/<dom_scribe> ->/g
16:23:37 <dom> RRSAgent, draft minutes
16:23:37 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/26-mediacap-minutes.html dom
16:25:01 <dom> trackbot, end meeting
16:25:01 <trackbot> Zakim, list attendees
16:25:01 <Zakim> sorry, trackbot, I don't know what conference this is
16:25:09 <trackbot> RRSAgent, please draft minutes
16:25:09 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/26-mediacap-minutes.html trackbot
16:25:10 <trackbot> RRSAgent, bye
16:25:10 <RRSAgent> I see no action items