12:17:54 RRSAgent has joined #mediacap 12:17:54 logging to http://www.w3.org/2012/10/30-mediacap-irc 12:17:56 RRSAgent, make logs public 12:17:56 Zakim has joined #mediacap 12:17:58 Zakim, this will be MCAP 12:17:58 I do not see a conference matching that name scheduled within the next hour, trackbot 12:17:59 Meeting: Media Capture Task Force Teleconference 12:17:59 Date: 30 October 2012 12:18:04 scribe: Milan 12:18:11 Meeting: Media Capture Task Force F2F at TPAC 2012 12:18:30 gmandyam has joined #mediacap 12:18:40 Canidate for dicusssion: Handling of multiple streams 12:18:49 dadhl has joined #mediacap 12:19:57 Another canidate: how setting properties on one track affects derived streams 12:20:00 tpacbot has joined #mediacap 12:20:18 adambe_ has joined #mediacap 12:20:23 s/Canidate/Candidate/ 12:20:31 another candidate: when to turn on the "green light" 12:20:38 i/Meeting: /Topic: Agenda bashing 12:21:07 Chair: stefanh, hta 12:21:36 Agenda: http://www.w3.org/wiki/Oct_30_2012 12:21:40 more candidate: fake (includes placeholder) streams 12:21:50 Travis has joined #mediacap 12:22:58 Stephan: what should we remove from the agenda? 12:24:00 jmarcon has joined #mediacap 12:24:06 Present+ Adambe, HTA, Anant, derf, burn, Milan, juberti, richt, natasha, giri, Travis, matthew, martin, ekr, fluffy, jmarcon, dom, stefanh 12:24:24 richt has joined #mediacap 12:24:30 Anant: fingerprinting requires less than 15 12:24:37 ... so may as well make that zero 12:26:02 Harald: What does it mean to remove stream from PC? Answered with arrays are stupid. 12:26:14 Dom: fingerprinting will be discussed tomorrow during plenary breakout, whose time and place will be decided during agenda building between 9:30-10:30 12:26:47 Travis: getTrackByName() is how HTML works 12:27:05 ... our groups needs to have multiple active video streams 12:27:21 s/getTrackByName/getTrackById/ 12:27:25 Stephan, perhaps we start with constraints and settings 12:27:40 -> http://dev.w3.org/html5/spec/media-elements.html#dom-audiotracklist-gettrackbyid getTrackById in HTML5 12:27:50 Travis: How about synchronization of tracks in a media stream 12:28:10 Jim: I have that in the recording discussion 12:28:38 Topic: Constraints and settings 12:28:49 DanB: Synchronization also needs to be included in the recording discussion 12:29:12 DanB: First slide 12:29:25 ... do we support runtime settings to v stream tracks 12:29:40 ... and what are the implications for peer connections 12:30:00 Stephan: what kinds of changes? 12:30:14 DanB: slide 2, settings proposal 12:30:17 +q 12:30:27 -> http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v4.html Proposal: Settings API Version 4 12:30:51 ... focusing on points of interest to WebRTC folks 12:31:05 ... media streams are device centric 12:31:32 ... getUserMedia() composed of tracks specific to the device type 12:31:59 ... tracks have relevant properties built into them 12:32:28 ... we'll get into the specifics of the properties later 12:32:38 ... slide 3 12:32:41 stephane has joined #mediacap 12:32:58 AndyH has joined #MEDIACAP 12:33:13 ... device discovery list by device type 12:33:46 ... once a single device has been approved, all other in that class exposed 12:34:00 Anant: what about permissions? 12:34:23 Travis: That's a good question that needs to be addressed 12:34:49 DanB: when a device goes away, a handler is fired 12:34:54 markus_ has joined #mediacap 12:35:16 ... constraints can be applied to set of devices 12:35:29 ... looking for a successful path 12:36:27 Travis: width.min and width.max instead of minwidth and maxwidth 12:36:44 Anant: why do we need a trial? 12:36:51 ... why not just apply 12:37:51 Zakim, move WebRTC to here 12:37:51 sorry, dom, I do not see a conference named 'WebRTC' in progress or scheduled at this time 12:38:12 Zakim, move MCAP to here 12:38:12 sorry, dom, I do not see a conference named 'MCAP' in progress or scheduled at this time 12:38:21 Zakim, move 9782 to here 12:38:22 ok, dom; that matches UW_Web RTC()3:00AM 12:38:43 Travis: purpose of trial is to use same constraints as would be used live 12:39:24 ... giving the developer the possibility for later selection 12:39:47 Anant: Trial is most useful for permission check 12:40:06 ... this is v4 spec 12:40:37 ... does this simply boil down to convenience? 12:40:40 Travis: yes 12:41:11 Anant: granting access to one device doesn't extend to others even in the same class 12:42:18 ... any extra functionality? 12:43:04 Travis: Aside from convenience, this allows a query for the number and capabilities of devices 12:43:16 ... which addresses the privacy concern 12:43:27 present+ Josh_Soref 12:43:45 Cullen: this is an expected user senario 12:44:32 +1 to dom's point 12:45:07 Ekr: Giving permission for one camera should not extend to another 12:45:26 Anant: perhaps we should wait for permissions answer 12:45:49 scribe: Josh_Soref 12:46:02 To clarify, what I am saying is that I don't see the relationship between being able to access a camera and being able to see the list of cameras 12:46:56 dom: when the user is first prompted the UA can let the user select which devices should be available 12:47:04 I think it is meant as a convenient shortcut, not as a logical relationship, ekr 12:47:15 Josh_Soref: +1 12:47:28 dom: i wouldn't base my schedule on getting a clear outcome from tomorrow's meetup 12:47:41 anant: either give list of devices up front, or don't 12:47:55 ... simply giving the full list after a first prompt doesn't seem to achieve anything 12:48:02 dom: it protects against drive by attacks 12:48:16 I'm not sure that I'm a fan of having multiple permission grants to do something like multi-camera telepresence either 12:48:24 q+ 12:48:24 ... if you provide some indication of a level of trust 12:48:39 ... i agree it's a bit flimsy, but it isn't entirely out 12:48:52 derf: we just ad this discussion 12:49:04 ... we changed our implementation to turn the green camera light as soon as you call getUserMedia 12:49:12 ... before we turn on the sink 12:49:24 ... we don't want the user to be surprised when the web page is able to turn the camera on 12:49:33 Travis: assuming they can trust your green light 12:49:38 derf: that's a different issue 12:49:46 ... the problem is now, i get the stream, i have the list of devices 12:49:52 ... i can switch to any of those cameras 12:50:00 ... do i need to turn all of their green lights on? 12:50:00 q+ 12:50:19 dom: i think it's a shortcut 12:50:28 ... there's a distinction between green lights and chrome indicators 12:50:32 q+ 12:50:36 dom: the distinction between green light and chrome indicator matters here as well 12:50:41 ack fluffy 12:50:45 fluffy: re: dom 12:50:50 ... there are two different permissions 12:50:53 ... permission to look at the list 12:50:58 ... permission to look at the camera 12:51:01 dom: asking twice 12:51:06 ... in most cases the user doesn't care 12:51:15 fluffy: yes, but you're asking us to ask twice 12:51:22 anant: he's saying the second permission implies the first 12:51:29 fluffy: that's a confusing experience to the user 12:51:36 ... click yes, you can see the list 12:51:41 ... but before you can't 12:51:45 dom: i don't disagree 12:51:51 ... i don't want to explain to my mother 12:51:57 ... i'm not quite convinced it's the right approach 12:52:03 ... it isn't a totally random approach 12:52:12 fluffy: there's two different permissions 12:52:18 ... how many times do we ask user to click yes 12:52:19 q? 12:52:22 ack gmandyam 12:52:23 q+ 12:52:27 q? 12:52:27 q+ 12:52:39 gmandyam: going back to before getUserMedia 12:52:39 q? 12:52:46 ... you have a video facing/front facing 12:52:49 ... i have an app 12:52:56 ... that needs use of a front facing camera 12:53:02 ... user gave me env facing camera 12:53:08 ... i go back to user "this app isn't going to work" 12:53:12 ... user is prompted again 12:53:17 ... gives front facing 12:53:21 ... i've determined he's got two 12:53:28 anant: how did you determine 12:53:40 gmandyam: with a change to the stream that indicates what it is 12:53:55 ... my proposal had the ability to ask for front facing in a constraint 12:54:04 ... with this, you got the user to disclose both cameras 12:54:16 ... -- this way you got the user to give the same info 12:54:23 ... i think it's a shorter way to get to the same result 12:55:08 Travis: before says something i don't like 12:55:16 ... once you got the device list, it's fair game to do anything you want 12:55:26 ... there will be a v5 that says "you can get the device list" 12:55:32 ... but to turn it on, you use getUserMedia 12:55:37 q? 12:55:44 Travis: v5 is same permission requests 12:55:53 q? 12:55:59 gmandyam: existing goes through same count of requests 12:56:20 tomoyuki has joined #mediacap 12:56:20 burn: obtaining access to a media stream means you get info about the stream 12:56:26 ... front/rear width/height 12:56:28 q? 12:56:31 ack me 12:56:48 Josh_Soref: so 12:57:00 [granting access to the list of devices could be optional, with a parameter in getUserMedia, with a checkbox in the authorization request] 12:57:01 q+ 12:57:15 ... my preferece is than when the first call to gUM is made, the user sees a list of devices 12:57:40 ... before I click OK on any camera I can see a preview of the camera 12:58:05 ... if I tap on one, and it doesn't show me the correct preview, I'll click another camera 12:58:42 ... we should try to design this that the app doesn't have to ask twice 12:59:17 ... the could be cases where you need additional cameras 12:59:33 ... the user selects one plus a set of other granted cameras 12:59:46 josh: the gent user media interface should show the user a preview windows that allows choosing the correct camera 13:00:00 ... the app gets the granted device with an additonal list of other granted devices 13:00:08 s/preferece/preference/ 13:00:10 Zakim, close the queue 13:00:10 ok, dom, the speaker queue is closed 13:00:17 Travis: i'd implement that 13:00:18 q? 13:00:24 ack ekr 13:00:37 there was more to it than that, the idea of a multi-select for "the" camera and several other cameras was proposed 13:00:37 ekr: my experience w/ apps is there's a need for the app to have camera switching 13:00:38 ... hangouts 13:00:41 ... webx 13:00:45 s/webx/webex/ 13:00:50 ... there's a need to enumerate 13:01:00 ... there's a question of whether there's a need for permission 13:01:05 ... i've heard "none are needed" 13:01:08 ... "permissions are needed" 13:01:13 ... "implicit permissions" 13:01:19 ... i'd vote for no permissions to enumerate 13:01:23 ... permission to activate 13:01:31 anant: every switch requires permissions? 13:01:38 ekr: every new acquisition requires permission 13:01:41 q? 13:01:48 anant: Josh_Soref 's thing only works for front/back 13:01:53 ... that doesn't work for other cases 13:01:58 ... front/back is so useless 13:02:03 ... cameras can rotate 360 degrees 13:02:08 ... i think constraints are important 13:02:16 ... you can't rely on users to pick the right device 13:02:22 ... if fingerprinting isn't an issue, i +1 ekr 13:02:30 ... for UCs, do you need a device name / constraints 13:02:37 ... or just a count of video/audio 13:02:47 ... i'd argue for minimal info 13:02:57 front/back is useful _relative to the device frame_. That's irrespecitve of whether you can rotate any given camera 360 degrees or not. 13:02:57 ... they'll know about constraints when they call getUserMedia 13:03:07 ... they can assign labels/ids - i don't care 13:03:15 ... we have a prototype 13:03:30 ... where you pass device:n to get info for that device 13:03:34 s/we/we-mozilla/ 13:03:41 ... we use that for our own chrome 13:03:50 q? 13:03:53 ack anant 13:03:55 ack adambe 13:04:02 adambe: fluffy, you had a good point 13:04:10 ... an app asks, wants permission for a camera 13:04:17 ... but you really want a list 13:04:19 ... that's silly 13:04:29 ... perhaps it would make sense to let the app ask to enumerate 13:04:39 ... and then it could actually, from the list, find a camera 13:04:44 ... and prompt the user, show self view 13:04:52 ... i don't think previous discussion about this in WhatWG 13:04:56 ... getting something + clicking ok 13:05:03 ... you had to do an active selection 13:05:09 ... in a file dialog 13:05:11 ... you're browsing 13:05:16 ... just clicking ok isn't really safe 13:05:25 ... we don't want apps to request a dummy to enumerate 13:05:30 ... i think it'll be pretty common 13:05:33 q? 13:05:34 q? 13:05:35 ack dom 13:05:44 dom: enumeration of hardware isn't the only fingerprinting issue 13:05:49 ... there's also hardware class 13:05:52 ... what Josh_Soref said earlier 13:06:03 ... to link the call to getUserMedia to granting access to several cameras at once 13:06:09 ... UI work on doing that is non trivial 13:06:13 .... i think it's a good idea 13:06:21 ... what adambe said, 13:06:31 ... i want access to a camera, but also a list to other cameras on this hardware 13:06:47 ... and have a ui for a checkbox "let this app have info about list on this device" 13:06:51 q? 13:07:01 Zakim, reopen the queue 13:07:02 ok, dom, the speaker queue is open 13:07:03 Zakim, open the queu 13:07:03 I don't understand 'open the queu', Josh_Soref 13:07:22 [ Slide Travis's settings proposal v4 ] 13:07:25 Zakim: open the queue 13:07:30 burn: specific value constraints 13:07:36 ... instead of a setting is 13:07:40 ... max/min together 13:07:43 ... to give one value 13:07:43 q+ 13:07:49 q- 13:07:52 ... you allow max+min 13:07:58 ... but focus is on this value 13:08:01 ... width=value 13:08:06 ... enumerated list = value 13:08:13 ... different from constraints which have ranges 13:08:19 ... or it's constraints where max=minn 13:08:23 q+ 13:08:24 s/minn/min/ 13:08:26 +q 13:08:30 ... settings override constraints 13:08:35 s/+q/q+/G 13:08:40 q+ 13:08:44 ... it doesn't matter what was set before, you set something new 13:08:48 ... and that's what can be adopted 13:08:57 ... let's keep this short 13:08:59 ack hta 13:09:07 hta: what i liked about v4 13:09:12 ... i think i can see how to map them onto constraints 13:09:13 juberti has joined #mediacap 13:09:25 ... so we have an underlying self consistent constraint based layer 13:09:26 q+ 13:09:30 ... i didn't see the logic picture 13:10:11 derf: or you get "pick closest value" 13:10:20 gmandyam: is the value change async 13:10:26 ... with a callback 13:10:27 q+ 13:10:35 ... settings aren't applied async, they're sync 13:10:41 ... i set zoom/redeye 13:10:49 ... i immediately make the call, and don't need a callback 13:11:01 ... we need to understand if settings are async 13:11:06 q? 13:11:08 can you set zoom atomically and immediately like that? 13:11:11 Travis: as an implementer, when you talk to random cameras 13:11:15 ... if you make that sync 13:11:18 q+ 13:11:18 ... it's a problem 13:11:25 ... same problem as sync file system access 13:11:31 gmandyam: then you need to address that in v5 13:11:34 ... we're ok with that 13:11:36 ack gmandyam 13:11:43 ... my internal guys want async 13:12:19 q- 13:12:19 [ demo of zoom taking time ] 13:12:32 anant: white balance is a discrete value 13:12:39 ... you might benefit from constraints and not settings 13:12:47 ... you'll know if it fails/succeeds 13:12:56 ... if you specify mandatory on an existing stream 13:13:01 ... you'll get a failure callback 13:13:07 Travis: or it turns off your callback 13:13:14 s/callback/camera/ 13:13:22 anant: i'd expect you to call the failure callback 13:13:24 ... not turn off the camera 13:13:27 ... we just define that 13:13:40 ... my feeling is we offer getUserMedia like thing on track/stream 13:13:46 q? 13:13:51 ack anant 13:13:52 juberti: XXZ 13:13:54 ack juberti 13:13:58 +1 to anant, juberti 13:14:01 juberti: agree with anant 13:14:10 burn: currently in v4 proposal that's done on the device type specific track 13:14:16 ... that's different from getUserMedia 13:14:19 q+ 13:14:21 q+ 13:14:22 ... you could get any new device that satisfies constraints 13:14:27 anant: keep that 13:14:34 juberti: camera is open to resolution X 13:14:40 ... you specify resolution Y 13:14:45 ... does that crop/scale? 13:14:49 Travis: i don't know 13:14:49 q- 13:14:51 juberti: i want both 13:14:56 Zakim, close the queue 13:14:56 ok, Josh_Soref, the speaker queue is closed 13:15:04 richt: constraints/values in summary 13:15:08 ... constraints are ranges 13:15:11 ... this is about specific things 13:15:17 ... but width/height is fishing blind 13:15:19 ... it's a range 13:15:30 ... settings is a responsive reaction to what's available 13:15:34 ack richt 13:15:40 q 13:15:42 +q 13:15:50 ... it's much more focused on responding to user's hardware 13:15:54 ack fluffy 13:15:59 fluffy: +1 on anant 's proposal 13:16:07 ... a lot of constraints aren't ranges 13:16:17 ... i always thought they encompassed settings types 13:16:27 ... i think we always needed to be able to change things on a track 13:16:30 ... some may feed to camera 13:16:38 ... or do it internally if not 13:16:46 ... i hope they don't scale up 13:16:55 Picture specific settings should not have to be enumerated in the RTCWeb Media Constraints doc 13:16:59 ... can you have 2 tracks cloned off eachother at different resolutions from the same camera? 13:17:01 Travis: +1 13:17:06 Zakim, open the queue 13:17:06 ok, Josh_Soref, the speaker queue is open 13:17:17 [ Impacts on Peer Connections ] 13:17:31 burn: settings proposal includes device-info 13:17:36 ... not just track info 13:17:43 ... info about what device is giving right now 13:17:53 Travis: there are a very small number of track level additions 13:18:03 ... width/height not coming from device 13:18:07 ... it's mostly device 13:18:12 burn: peer connections 13:18:15 ... what happens 13:18:24 ... if you have a video media stream track 13:18:29 ... with specific width / height 13:18:35 ... and you add it to a peer connection 13:18:42 q+ 13:18:42 ... what can you expect to happen at other end 13:18:47 ... when it arrives at other end 13:18:55 ... is it still a video stream track 13:19:03 ... could someone change it at the other end? 13:19:08 q? 13:19:16 ... currently. constraints in peer connection 13:19:16 q+ 13:19:31 ... specific characteristics of media can be changed on the fly by browser as necessary 13:19:37 ... as long as they continue to satisfy the constraints 13:19:45 ... for congestion control, whatever reasons the UA wants 13:19:54 ... how does that work w/ or not w/ settings 13:20:04 ... then device track swapping w/in stream 13:20:05 q? 13:20:07 ack anant 13:20:16 anant: i like removal of local-media-stream 13:20:27 ... i think transmitter is always in control 13:20:34 ... if you apply changes on one side 13:20:39 ... [sender?] 13:20:39 q+ 13:20:43 ... that should apply on the other side 13:20:48 ... i think if you apply changes 13:20:56 ... the UA can decide what to do 13:20:58 q+ 13:21:05 burn: application requests change where? and where is change applied? 13:21:08 q+ 13:21:16 anant: browser A getUserMedia camera 13:21:17 q+ 13:21:22 ... sends camera to browser B 13:21:34 ... browser A changes constraint for stream 13:21:36 Jim_Barnett has joined #mediacap 13:21:40 ... and is applied to stream seen in browser B 13:21:44 ... on browser B 13:21:53 ... if application there makes a constraint request change 13:21:58 ... depends on what is asked for 13:22:02 ... if it's a scale-down 13:22:07 ... browser B can decide to do it 13:22:15 ... in cases it can't 13:22:17 ... call failure 13:22:26 ... no device/peer connection 13:22:37 Travis: browser B receiving stream from peer connection 13:22:43 ... it thinks peer connection is a source 13:22:53 q? 13:22:55 ... since it doesn't own source, it can do some operations 13:23:00 anant: yes, that's what i'm proposing 13:23:03 gape has joined #mediacap 13:23:08 ... scale down yes 13:23:12 ... white balance maybe not? 13:23:16 ack stefanh 13:23:22 stefanh: we discussed some of this yesterday 13:23:31 ... what should happen if you modify media stream track 13:23:31 q+ 13:23:45 q+ to ask if browser B has a constraint 13:23:56 q+ 13:23:56 q+ to ask if browser B has a constraint and browser A changes constraint to violate B's 13:24:14 anant: when you specify a constraint request that violates the stream 13:24:26 ... the stream should remain unchanged 13:24:28 ... and call failure 13:24:36 adambe: what if browser is doing things to keep stream alive? 13:24:39 anant: unknown 13:24:46 ack adambe 13:24:47 adambe: about picture device track 13:24:52 ... will those live on their own? 13:24:57 Travis: fuzzy in proposal 13:25:07 ... to gauge reaction of group 13:25:14 ... picture track could act like a video track 13:25:28 adambe: think it's helpful if it's coupled to a video device track 13:25:31 ... something you can feature probe 13:25:34 Dini_Martini has joined #mediacap 13:25:38 ... provides extra functionality 13:25:41 ... inheritance 13:25:51 ... properties containing others... 13:25:55 ... [hand waving] 13:26:06 ... seems it'd be better as an extra feature coupled to parrent 13:26:12 s/parrent/parent/ 13:26:12 ack dm 13:26:15 ack gmandyam 13:26:17 q? 13:26:19 +1 to what adam just suggested, PictureDevice is not a track 13:26:23 gmandyam: webrtc says most streams are read only 13:26:33 ... can't do things except on sender side 13:26:39 s/most streams/remote streams/ 13:26:42 ... not sure what to do if receiver isn't satisfied 13:26:45 ... how does that work 13:26:54 ... stream is readonly 13:26:58 if i have synthetic tracks that come from files, wouldn't picturedevice possibly represent a slide show of a folder of pictures (perhaps not encodable as video)? 13:26:59 anant: failure callback 13:27:02 ... browser can't make change 13:27:14 Travis: don't you need to put it in a