19:58:39 <RRSAgent> RRSAgent has joined #mediacap
19:58:39 <RRSAgent> logging to http://www.w3.org/2012/10/09-mediacap-irc
19:58:41 <trackbot> RRSAgent, make logs public
19:58:41 <Zakim> Zakim has joined #mediacap
19:58:43 <trackbot> Zakim, this will be MCAP
19:58:43 <Zakim> ok, trackbot; I see UW_MdCap()4:00PM scheduled to start in 2 minutes
19:58:44 <trackbot> Meeting: Media Capture Task Force Teleconference
19:58:44 <trackbot> Date: 09 October 2012
19:58:50 <Travis> Travis has joined #mediacap
19:59:35 <hta> hta has joined #mediacap
19:59:47 <hta> zakim, who is here?
19:59:47 <Zakim> UW_MdCap()4:00PM has not yet started, hta
19:59:48 <Zakim> On IRC I see hta, Travis, Zakim, RRSAgent, stefanh, richt_, Josh_Soref, derf, trackbot, dom
20:00:01 <dom> Zakim, code?
20:00:01 <Zakim> the conference code is 6227 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), dom
20:00:07 <dom> Agenda: http://lists.w3.org/Archives/Public/public-media-capture/2012Oct/0005.html
20:00:17 <dom> Chair: hta, stefanh
20:00:20 <hta> zakim, who is here?
20:00:20 <Zakim> UW_MdCap()4:00PM has not yet started, hta
20:00:22 <Zakim> On IRC I see hta, Travis, Zakim, RRSAgent, stefanh, richt_, Josh_Soref, derf, trackbot, dom
20:00:41 <hta> dom, is zakim's clock broken?
20:00:49 <Josh_Soref> scribe: Josh_Soref
20:01:18 <stefanh> Josh, thanks!
20:01:20 <Travis> Present+ Travis_Leithead
20:01:51 <mreavy> mreavy has joined #mediacap
20:01:51 <jesup> jesup has joined #mediacap
20:02:04 <gmandyam> gmandyam has joined #mediacap
20:02:27 <dom> Zakim, who's on the call?
20:02:27 <Zakim> UW_MdCap()4:00PM has not yet started, dom
20:02:29 <Zakim> On IRC I see gmandyam, jesup, mreavy, hta, Travis, Zakim, RRSAgent, stefanh, richt_, Josh_Soref, derf, trackbot, dom
20:02:37 <dom> Present+ Dominique_Hazael-Massieux
20:02:57 <stefanh> Present+ Stefan_Hakansson
20:03:02 <adambe> adambe has joined #mediacap
20:04:42 <stefanh> Josh, are you getting ready?
20:04:42 <hta> someone is talking, but apparently can't hear us.
20:04:47 <hta> We hear that person.
20:04:57 <Josh_Soref> Zakim, mute me
20:04:57 <Zakim> sorry, Josh_Soref, I don't know what conference this is
20:05:52 <Josh_Soref> RRSAgent, draft minutes
20:05:52 <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/09-mediacap-minutes.html Josh_Soref
20:06:00 <Josh_Soref> RRSAgent, make logs public
20:06:16 <Josh_Soref> s/Josh, thanks!//
20:06:23 <Josh_Soref> s/Josh, are you getting ready?//
20:06:30 <Josh_Soref> s/someone is talking, but apparently can't hear us.//
20:06:37 <Josh_Soref> s/We hear that person.//
20:06:41 <Josh_Soref> present+ Josh_Soref
20:06:47 <gmandyam> Giri Mandyam (Qualcomm Innovation Center) dialing in from (858) area code
20:06:50 <dom> Present+ Eric_Rescorla
20:06:55 <dom> Present+ Jim_Barnett
20:06:56 <Josh_Soref> present+ Jim_Barnett
20:07:07 <dom> Present+ Giri_Mandyam
20:07:09 <Josh_Soref> s/present+ Jim_Barnett//
20:07:20 <Josh_Soref> s/Giri Mandyam (Qualcomm Innovation Center) dialing in from (858) area code//
20:07:30 <Jim_Barnett> Jim_Barnett has joined #mediacap
20:07:42 <stefanh> MoM last meeting: http://lists.w3.org/Archives/Public/public-media-capture/2012Aug/0149.html
20:07:56 <Josh_Soref> i/MoM/Topic: Minutes Approval/
20:08:04 <Josh_Soref> Resolution: Minutes from last meeting are approved
20:08:33 <Josh_Soref> Topic: capture settings of a MediaStreamTrack
20:09:02 <Josh_Soref> present+ Travis 
20:09:14 <Travis> http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v4.html
20:09:19 <Josh_Soref> s/present+ Travis//
20:09:30 <Josh_Soref> Travis: talking about the proposal made last week
20:09:35 <Josh_Soref> ... this is an update of multiple previous proposals
20:09:46 <Josh_Soref> ... particularly for device settings, such as microphones/web cameras
20:10:08 <Josh_Soref> ... the first section describes a proposal to remove the existing notion of a LocalMediaStream
20:10:08 <anant> anant has joined #mediacap
20:10:11 <Josh_Soref> ... along with the rationale
20:11:30 <Josh_Soref> ... the second section describes how we propose creating multiple kinds of track objects
20:11:44 <Josh_Soref> ... today we have a vanilla-generic MediaStream Track object
20:11:55 <Josh_Soref> ... this proposal factors it out into Video and Audio Track objects
20:12:02 <Josh_Soref> ... and further factors them to Video and Audio devices
20:12:20 <Josh_Soref> ... the third section describes the mechanism for making changes to settings
20:12:23 <Josh_Soref> ... and reading seettings back
20:12:41 <Josh_Soref> ... a setting can either take an Enumerated set of values, or a Range of values
20:12:47 <Josh_Soref> ... it also provides a list of proposed settings
20:12:51 <Josh_Soref> ... for Cameras
20:12:55 <Josh_Soref> ... as well as for Microphones
20:13:10 <Josh_Soref> ... and it describes the event(s) that fire as a result of a settings change
20:13:17 <Josh_Soref> ... the fourth section covers a Device List
20:13:33 <Josh_Soref> ... a way for a web developer to discretely discover devices
20:13:51 <Josh_Soref> ... starting from getUserMedia
20:14:11 <Josh_Soref> ... the Device List is a list of obtainable objects
20:14:19 <Josh_Soref> ... but a web page wouldn't automatically get it
20:14:35 <Josh_Soref> ... the fifth, and last section, is a proposed set of Constraints relating to section 3
20:14:41 <Josh_Soref> ... for use with getUserMedia
20:15:18 <Josh_Soref> ... there's also examples for how this would work to accomplish scenairos
20:15:24 <Josh_Soref> s/iros/rios/
20:15:33 <Josh_Soref> ... let me recap the feedback i've received so fatr
20:15:36 <Josh_Soref> s/fatr/far/
20:15:43 <Josh_Soref> ... very little feedback about section 1
20:15:51 <Josh_Soref> ... section 2 has received little feedback
20:16:01 <Josh_Soref> ... it harmonizes with a counter proposal that richt_ made last month
20:16:08 <Josh_Soref> ... it's essentially what he proposed
20:16:21 <Josh_Soref> ... it introduces the concept of a Picture Device Track
20:16:21 <gmandyam> q+
20:16:27 <Josh_Soref> ... i expected to hear feedback on this
20:16:33 <Josh_Soref> ... i'm curious to know the group's thoughts on that
20:16:43 <Josh_Soref> ... section 3... has received feedback on the mechanism for changing settings
20:16:57 <Josh_Soref> ... what happens when devices decide to alter settings as a result of the environment
20:17:02 <Josh_Soref> ... and how we respond to that
20:17:16 <Josh_Soref> ... and how we use the events (constraintSuccess, constraintError)
20:17:26 <Josh_Soref> ... most of the feedback is about section 4, the device list
20:17:32 <Josh_Soref> ... most of the feedback is about privacy
20:18:01 <anant> q+
20:18:35 <Josh_Soref> ... if i approve one camera, that doesn't imply i'm approving all cameras.
20:18:38 <Josh_Soref> ... that's good feedback, i'm working on how we could preserve this structure
20:18:48 <jesup> that's how I read it
20:18:54 <Josh_Soref> XX: my understanding is that you could only enumerate one type
20:19:03 <jesup> xx = ekr
20:19:05 <Josh_Soref> ... once you've been given permission for that type?
20:19:09 <Josh_Soref> s/XX:/ekr:/
20:19:41 <Josh_Soref> ... under no circumstances is approval of the front camera permission for access to the obverse camera
20:19:50 <Josh_Soref> Travis: i was very lenient at first about privacy issues
20:19:53 <jesup> This goes back to the entire 'fingerprinting' issue
20:20:05 <Josh_Soref> ... initially you can access a list of other devices of the same class
20:20:27 <Josh_Soref> ekr: it's imperative that there's no access to devices beyond what the user provides
20:20:34 <Josh_Soref> ... there's a distinct question relating to fingerprinting
20:20:45 <Josh_Soref> Travis: i think i understand your feedback
20:20:59 <Josh_Soref> ekr: you should be able to interrogate the list of devices at any time
20:21:11 <Josh_Soref> ... but any request to activate must be associated with a user action
20:21:16 <Josh_Soref> Travis: i think i agree with that
20:21:26 <Josh_Soref> ... we have another proposal variant
20:21:36 <Josh_Soref> ... which allows for inspection, but not enabling without consent
20:21:47 <Josh_Soref> ekr: i understand people objecting to enumeration
20:22:03 <Josh_Soref> ... but the people i speak to in security view access as a security block
20:22:11 <Josh_Soref> adambe: this relates to capabilities
20:22:16 <Josh_Soref> ... a range from all information about a camera
20:22:24 <Josh_Soref> ... down to is video/is audio
20:22:27 <Josh_Soref> ... down to nothing
20:22:37 <Josh_Soref> ... allowing an application to inspect the whole list is
20:22:42 <Josh_Soref> ... XXa1
20:22:48 <Josh_Soref> hta: there's a shift in the thinking about this
20:23:00 <Josh_Soref> ... i think people objected to getCapabilities
20:23:14 <Josh_Soref> ... if people have stopped objecting to that, it's certainly the simplest way forward
20:23:33 <Josh_Soref> adambe: i think we had consensus around hasAudio/hasVideo
20:23:40 <Josh_Soref> hta: i think we had consensus on deviceCount
20:23:53 <Josh_Soref> ... but not a clear consensus on what makes an application trusted
20:24:01 <Josh_Soref> adambe: i think that's correct
20:24:19 <Josh_Soref> ... not hearing someone objecting to unrestricted enumeration
20:24:26 <Josh_Soref> ... doesn't indicate there isn't objection
20:24:43 <Josh_Soref> anant: w3's security WG released a statement that "fingerprinting is no longer an issue"
20:24:47 <dom> (where was that statement made?)
20:24:49 <Josh_Soref> ... i think we're ok with enumeration
20:25:00 <Josh_Soref> ... enumeration is ok, but actual access is ok
20:25:12 <Josh_Soref> hta: anant, does enumeration include device capabilities?
20:25:24 <Josh_Soref> anant: are you talking about returning constraints?
20:25:27 <Josh_Soref> hta: yes
20:25:29 <Josh_Soref> anant: i think that's fine
20:25:37 <Josh_Soref> ... whatever we return in the list, i think is fine to return
20:25:41 <dom> q+ to ask about statement on fingerprinting
20:25:57 <Josh_Soref> hta: working hypothesis: any application can use getCapabilities at any time
20:26:03 <Josh_Soref> Travis: i'd like to voice my word of caution
20:26:21 <Josh_Soref> ... i backed the word of caution about not exposing arbitrary attributes
20:26:34 <Josh_Soref> ... based on the principle of fingerprinting
20:26:40 <Josh_Soref> ... while this may seem contradictory
20:26:46 <Josh_Soref> ... if a user has approved "a camera"
20:26:55 <Josh_Soref> ... i've crossed the first bridge
20:27:15 <Josh_Soref> ... and then if we take this a step further, allow the application to request permission for additional resources
20:27:24 <Josh_Soref> ... i'm not sure i'm comfortable with getCapabilities in a general sense
20:27:40 <Josh_Soref> ack gmandyam 
20:27:43 <dom> +1 on not comfortable on general getCapabilities
20:27:54 <Josh_Soref> gmandyam: you mentioned later in the document
20:28:09 <Josh_Soref> ... where would you have XXXgm?
20:28:23 <hta> s/XXXgm/Photo capabilitiies/
20:28:23 <Josh_Soref> Travis: the Video Device (like a web camera) may provide a Picture Device
20:28:36 <Josh_Soref> ... and you can use that device to apply settings to a high resolution picture
20:28:44 <Josh_Soref> ... those settings don't apply to the picture stream
20:28:52 <Josh_Soref> ... they only apply to the takePicture API
20:28:58 <jesup> This seems a reasonable way to handle video with pictures
20:29:03 <Josh_Soref> gmandyam: i didn't understand how preview would work
20:29:07 <Josh_Soref> ... wrt takePicture
20:29:19 <jesup> video stream is preview
20:29:41 <Josh_Soref> ... you should have a video stream continuously during the takePicture
20:29:58 <Josh_Soref> Travis: my thought is that the VideoDevice lets you configure your Video stream
20:30:02 <Josh_Soref> ... you can go into the PictureDevice
20:30:12 <Josh_Soref> ... which may support a 12mp resolution (i.e. much better than video)
20:30:22 <Josh_Soref> ... you could request that resolution on the PictureDevice
20:30:28 <Josh_Soref> ... that wouldn't affect your Video element
20:30:36 <Josh_Soref> ... but takePicture would apply those settings
20:30:48 <Josh_Soref> ... take the large (12mp image) and then return back to the Video stream resolution
20:30:54 <Josh_Soref> ... i spoke w/ the MS video team this morning
20:31:09 <Josh_Soref> ... relating to hta 's comment about cameras that dynamically resize their output for different reasons
20:31:22 <Josh_Soref> ... some cameras put settings for the camera to the maximum
20:31:31 <Josh_Soref> ... and the camera drivers resample it down for video
20:31:39 <Josh_Soref> ... so the sensor is working at high res
20:31:46 <Josh_Soref> ... that may dramatically reduce framerate
20:31:55 <hta> q?
20:31:56 <jesup> This matches the general thrust of what Mozilla was thinking of in picture capture IMHO
20:32:05 <Josh_Soref> ack anant 
20:32:11 <Josh_Soref> anant: i like takePicture
20:32:16 <Josh_Soref> ... we have an api we've implemented
20:32:32 <Josh_Soref> ... do you feel constraints for a PictureDevice are significantly different from a Video stream?
20:32:37 <Josh_Soref> ... to me, the answer seems to be yes
20:32:48 <Josh_Soref> ... filter/autofocus
20:33:04 <Josh_Soref> q+ to note that some video cameras support auto focus
20:33:13 <jesup> Pictures tend to have an almost-infinite set of parameters :-)
20:33:17 <Josh_Soref> ... for Firefox OS, we have an autofocus
20:33:29 <anant> https://wiki.mozilla.org/WebAPI/CameraControl
20:33:31 <Josh_Soref> ... You mentioned permissions
20:33:35 <anant> http://lists.w3.org/Archives/Public/public-webappsec/2012Sep/0048.html
20:34:22 <Josh_Soref> anant: in that message, he says that users concerned about tracking will need a special UA
20:34:34 <Josh_Soref> ... the UX for that doesn't seem great
20:34:48 <Josh_Soref> ... the first is "allow enumerate" and then "pick a camera"
20:35:11 <Josh_Soref> ... if we can get a nicer experience with only one popup, and somehow do enumeration after authorization
20:35:11 <dom> q+ to temperate the extent of "rough consensus on giving up on fingerprinting"
20:35:16 <Josh_Soref> ... i'm ok with that
20:35:16 <adambe> q+
20:35:35 <Josh_Soref> anant: how do you intend to expose Device List?
20:35:44 <Josh_Soref> Travis: you get it from an existing Device object
20:36:15 <Josh_Soref> anant: that seems convoluted
20:36:25 <Josh_Soref> ... i'd prefer a simpler approach
20:36:45 <Josh_Soref> ... sophisticated apps will want to enumerate first
20:36:50 <Josh_Soref> ... and then pick a device
20:37:11 <Josh_Soref> [ time check: 5 minutes remaining for this topic ]
20:37:39 <hta> q+
20:38:06 <Josh_Soref> ack me
20:38:06 <Zakim> Josh_Soref, you wanted to note that some video cameras support auto focus
20:38:17 <Josh_Soref> Zakim, mute me
20:38:17 <Zakim> sorry, Josh_Soref, I don't know what conference this is
20:38:39 <dom> Zakim, this is MCAP
20:38:39 <Zakim> ok, dom; that matches UW_MdCap()4:00PM
20:38:45 <dom> Zakim, who's on the call?
20:38:45 <Zakim> On the phone I see +46.1.07.14.aaaa, +1.650.241.aabb, +91.22.39.14.aacc, [Microsoft], +1.289.261.aadd, +1.610.889.aaee, +1.858.651.aaff, Jim_Barnett, +46.1.07.14.aagg, ??P6,
20:38:48 <Zakim> ... [Mozilla], ??P11
20:38:57 <Josh_Soref> Zakim, aadd is me
20:38:57 <Zakim> +Josh_Soref; got it
20:39:06 <stefanh> zakim, aaaa is me
20:39:06 <Zakim> +stefanh; got it
20:39:12 <Josh_Soref> adambe: on anant 's comments
20:39:22 <gmandyam> Zakim, aaff is me
20:39:22 <Zakim> +gmandyam; got it
20:39:25 <jesup> zakim, aaee is me
20:39:25 <Zakim> +jesup; got it
20:39:47 <dom> q+ to test his mike
20:39:52 <Josh_Soref> adambe: trying to enumerate first triggers two popups
20:40:03 <dom> Zakim, who's noisy?
20:40:07 <Josh_Soref> XXz: for every device, there's at least one popup
20:40:11 <hta> zakim, aabb is me
20:40:11 <Zakim> +hta; got it
20:40:15 <Zakim> dom, listening for 11 seconds I heard sound from the following: +1.650.241.aabb (4%), +91.22.39.14.aacc (65%), [Mozilla] (56%), ??P11 (57%)
20:40:23 <stefanh> s/XXv/adambe/
20:40:23 <Josh_Soref> Zakim, mute aacc
20:40:23 <Zakim> +91.22.39.14.aacc should now be muted
20:40:23 <dom> Zakim, mute aacc
20:40:24 <Zakim> +91.22.39.14.aacc was already muted, dom
20:40:30 <Josh_Soref> Zakim, mute ??P11
20:40:30 <Zakim> ??P11 should now be muted
20:40:39 <anant> s/XXz/adambe
20:40:53 <Josh_Soref> XXw: in Aurora, the popup has a chooser
20:40:59 <Josh_Soref> ... to let you pick the device you want
20:41:11 <Josh_Soref> ... if you look at Google Hangouts
20:41:19 <Josh_Soref> ... it has an in content interface to select which devices you want
20:41:31 <Josh_Soref> ... how much of that interface would continue to be possible under WebRTC
20:41:36 <Josh_Soref> ... what should a site be able to do?
20:41:41 <Josh_Soref> ... as that would inform what to offer the user
20:41:54 <hta> q?
20:42:02 <Josh_Soref> Zakim, who is making noinse
20:42:02 <Zakim> I don't understand 'who is making noinse', Josh_Soref
20:42:05 <Josh_Soref> Zakim, who is making noise?
20:42:06 <adambe> ekr is speaking
20:42:11 <Josh_Soref> s/XXw/ekr/
20:42:20 <Josh_Soref> ... i don't want two choosers
20:42:21 <Zakim> Josh_Soref, listening for 10 seconds I heard sound from the following: hta (14%), +46.1.07.14.aagg (10%)
20:42:25 <Josh_Soref> ... and have that be XXek for the user
20:42:43 <Josh_Soref> XXf: last week we were cautious about fingerprinting
20:42:45 <Josh_Soref> ... and today we aren't
20:42:49 <Josh_Soref> ... it feels strange
20:42:55 <dom> Zakim, unmute ??P11
20:42:55 <Zakim> ??P11 should no longer be muted
20:43:05 <hta> ack dom
20:43:05 <Zakim> dom, you wanted to ask about statement on fingerprinting and to temperate the extent of "rough consensus on giving up on fingerprinting" and to test his mike
20:43:06 <Josh_Soref> Zakim, who is making noise?
20:43:13 <dom> Zakim, drop ??P6
20:43:13 <Zakim> ??P6 is being disconnected
20:43:14 <Zakim> -??P6
20:43:19 <stefanh> s/XXf/adambe/
20:43:20 <Zakim> Josh_Soref, listening for 11 seconds I heard sound from the following: stefanh (8%), hta (8%), Jim_Barnett (4%), [Mozilla] (13%), ??P11 (70%)
20:43:31 <Josh_Soref> Zakim, ??P11 is dom 
20:43:31 <Zakim> +dom; got it
20:43:34 <adambe> how do I mark myself as done speaking?
20:43:40 <Josh_Soref> dom: anant, thanks for that link
20:43:54 <Josh_Soref> ... i wouldn't say that their link is a statement of the world in W3C
20:44:02 <Josh_Soref> ... it's limited to web apps sec
20:44:08 <Josh_Soref> ... i was on a privacy call two weeks ago
20:44:14 <Josh_Soref> ... and i don't think that's their view
20:44:19 <stefanh> @adambe: "ack me"
20:44:25 <Josh_Soref> ... i don't think that view is broadly accepted
20:44:29 <adambe> q?
20:44:32 <Josh_Soref> ... i'm happy to take an action to research that
20:44:39 <adambe> Zakim: ack me
20:44:43 <adambe> q?
20:44:46 <adambe> ack me
20:44:46 <Josh_Soref> ekr: i cochair webappsec with bradh
20:44:50 <adambe> q?
20:45:00 <Josh_Soref> ... it wasn't a statement on behalf of the Web App Sec WG
20:45:04 <Josh_Soref> Zakim, who is making noise?
20:45:19 <Zakim> Josh_Soref, listening for 12 seconds I heard sound from the following: [Mozilla] (100%), dom (69%)
20:45:26 <Josh_Soref> Zakim, mute dom
20:45:26 <Zakim> dom should now be muted
20:45:35 <dom> ack me
20:45:55 <Josh_Soref> ekr: we should probably have a meeting at TPAC to talk about this
20:46:03 <Josh_Soref> dom: i agree that it makes sense to talk about this at TPAC
20:46:04 <hta> action dom: clarify W3C position on fingerprinting
20:46:04 <trackbot> Created ACTION-10 - Clarify W3C position on fingerprinting [on Dominique Hazaël-Massieux - due 2012-10-16].
20:46:16 <Josh_Soref> ... coming back to this WG
20:46:31 <Josh_Soref> ... i'd be very cautious about making design decisions assuming this is no longer a concern
20:46:33 <hta> ack me
20:46:52 <Josh_Soref> Topic: Constraints and Memory
20:46:59 <Josh_Soref> Zakim, who is making noise?
20:47:01 <Josh_Soref> Zakim, mute dom
20:47:01 <Zakim> dom should now be muted
20:47:11 <Josh_Soref> hta: once you get a device
20:47:14 <Zakim> Josh_Soref, listening for 13 seconds I heard sound from the following: hta (72%), Jim_Barnett (3%)
20:47:18 <Josh_Soref> ... after having specified constraints
20:47:25 <dom> q+ to ask about modularity and schedule (for a change :)
20:47:39 <Josh_Soref> ... take as a given that some devices will change their configuration
20:47:50 <Josh_Soref> ... should an application expect a device to stay within constraints?
20:47:59 <Josh_Soref> ... or should they expect it wanders outside?
20:48:10 <Travis> q+ devices that change configuration is not a given...
20:48:18 <Josh_Soref> ... if we ask to change its configuration
20:48:21 <Travis> q+
20:48:34 <Josh_Soref> ... can we expect that all previously applied constraints are still applicable (unless overridden)
20:48:42 <Josh_Soref> XXcc: XXcd?
20:49:00 <Josh_Soref> Travis: i want to question that devices will change their configuration
20:49:05 <Josh_Soref> ... that may be true for a peer connection
20:49:15 <Josh_Soref> ... but for a device (camera/microphone), it's never the device
20:49:21 <Josh_Soref> ... but perhaps the OS that responds to input
20:49:41 <Josh_Soref> hta: i was using "Device" as shorthand for "device, drivers, and everything else beyond the browser"
20:49:42 <jesup> Disagree, dsp-enabled-cameras will adapt frame rates with no OS input I believe
20:49:53 <jesup> q+
20:49:55 <Josh_Soref> ... mac cameras are famous for adjusting framerate under low-light conditions
20:50:00 <Josh_Soref> Travis: that's the mac os doing it
20:50:07 <Josh_Soref> ... not the camera under its own volition
20:50:12 <Josh_Soref> hta: it's hard to see where that line is
20:50:29 <Josh_Soref> ... if we accept "device" as "everything below the api surface"
20:50:33 <Josh_Soref> Travis: the platform evolves
20:50:42 <Josh_Soref> ... we have apis exposing environmental sensors
20:50:53 <Josh_Soref> ... you may want to implement these in the application itself
20:51:00 <Josh_Soref> ... we should provide the way to do those things if you want to
20:51:17 <Josh_Soref> ... make the assumption that the device is a consistent mechanism
20:51:27 <Josh_Soref> ... apply state, read state
20:51:30 <Josh_Soref> ... be able to depend on that
20:51:33 <Josh_Soref> hta: i'm skeptical
20:51:35 <Josh_Soref> q?
20:51:46 <Josh_Soref> ack dom 
20:51:48 <Zakim> dom, you wanted to ask about modularity and schedule (for a change :)
20:51:49 <Travis> q-
20:51:51 <stefanh> q+
20:52:22 <Josh_Soref> dom: this api brings a number of fairly deep changes
20:52:32 <Josh_Soref> ... i'm wondering what the plan is around the schedule for this set of features
20:52:38 <Josh_Soref> ... is this part of the main spec
20:52:41 <Josh_Soref> ... is it a distinct module?
20:52:46 <dom> Zakim, mute me
20:52:46 <Zakim> dom should now be muted
20:52:47 <Josh_Soref> ... are we slipping our schedule?
20:52:56 <hta> q?
20:53:02 <dom> ack me
20:53:04 <Josh_Soref> stefanh: feedback we've gotten is that the MediaStream api wasn't supported
20:53:09 <Josh_Soref> ... people wanted additional features
20:53:20 <Josh_Soref> ... i guess we're slipping
20:53:49 <Josh_Soref> dom: does that mean implementers aren't shipping getUserMedia?
20:53:55 <Josh_Soref> ... i know MS doesn't announce shipping plans
20:54:00 <Josh_Soref> ... maybe mozilla can comment?
20:54:09 <Josh_Soref> anant: we want to support getUserMedia and MediaStream
20:54:11 <Josh_Soref> Zakim, mute dom
20:54:11 <Zakim> dom should now be muted
20:54:17 <Josh_Soref> ... we don't support everything
20:54:24 <dom> ack me
20:54:30 <Josh_Soref> ... our intention is to support everything from getUserMedia/MediaStream as in the draft
20:54:47 <Josh_Soref> dom: that conditions the work of the simple getUserMedia api
20:54:57 <hta> q?
20:55:00 <hta> ack jesup
20:55:01 <Josh_Soref> so XXXing our schedule seems reasonable
20:55:05 <Josh_Soref> Zakim, mute dom
20:55:05 <Zakim> dom should now be muted
20:55:16 <Josh_Soref> jesup: about hardware/dumb-hardware/smart-hardware
20:55:22 <Josh_Soref> ... my experience from embedded devices
20:55:35 <Josh_Soref> ... webcams do adaptations automatically unless you stop them
20:55:40 <Josh_Soref> ... maybe the OS can do this
20:55:46 <Josh_Soref> ... whether the OS/camera does it
20:55:54 <Josh_Soref> ... the framerate varies according to light level
20:56:00 <Josh_Soref> ... we shouldn't assume the hardware is dumb
20:56:07 <Josh_Soref> ... assume the hardware may be more active than that
20:56:14 <Josh_Soref> ... be prepared for that
20:56:20 <Josh_Soref> ... it's going to be
20:56:25 <Josh_Soref> ... and in many cases it already is
20:56:29 <hta> ack stefanh
20:56:46 <dom> s/XXX/stick/
20:56:57 <Josh_Soref> stefanh: XXY
20:57:44 <Josh_Soref> ... can you elaborate on the relation between getUserMedia constraints and constraints in the request operation
20:57:49 <Josh_Soref> s/XXX/.../
20:57:58 <Josh_Soref> Travis: the proposal defines constraints for Video/Audio in section 5
20:58:02 <Josh_Soref> ... e.g. a width/height constraint
20:58:07 <Josh_Soref> ... either a number or min-max range
20:58:15 <Josh_Soref> ... the request api
20:58:19 <Josh_Soref> ... when you invoke for a settings change
20:58:25 <Josh_Soref> ... they build up iteratively
20:58:33 <Josh_Soref> ... so if you change 1024x768 to 800x600
20:58:38 <Josh_Soref> ... you request 800x600
20:59:07 <Josh_Soref> ... each time you make a request, you build onto the structure being generated for you
20:59:22 <Josh_Soref> ... when your context ends, the constraints being built are applied
20:59:31 <Josh_Soref> ... a question applies to specific values or ranges
21:00:02 <Josh_Soref> stefanh: if you start with 25-30hz
21:00:09 <Josh_Soref> ... and then XXa?
21:00:19 <hta> s/XXa/15hz/
21:00:21 <Josh_Soref> ... if it's outside your original constraints, is that ok?
21:00:39 <Josh_Soref> Travis: if you specify within the device range
21:00:44 <Josh_Soref> ... but outside the getUserMedia request
21:00:48 <Josh_Soref> ... you still try to honor that
21:01:15 <Josh_Soref> hta: any other comments?
21:01:16 <Josh_Soref> q?
21:01:48 <Josh_Soref> Topic: Recording API proposal
21:02:01 <dom> (I guess we haven't quite determined how we integrate this in the spec, but we can figure that after the call)
21:02:11 <Josh_Soref> Jim_Barnett: 4 high level questions
21:02:22 <stefanh> http://lists.w3.org/Archives/Public/public-media-capture/2012Oct/0010.html
21:02:31 <Josh_Soref> ... do we want recording to be a separate interface or a partial?
21:02:34 <jesup> separate interface++
21:02:37 <Josh_Soref> ... a lot of people like a separate one
21:02:49 <Josh_Soref> ... Travis identified not likely allowing overlapping recordings
21:02:59 <Josh_Soref> ... what's the relationship between recording and media capture?
21:03:14 <Josh_Soref> ... if there are separate apis, we might be able to make things simpler with a lower level api?
21:03:19 <Josh_Soref> ... XXf?
21:03:29 <Josh_Soref> ... do we think there are any XXg formats?
21:03:44 <jesup> I suggest to the list generally
21:03:44 <stefanh> s/XXg/MTI/
21:04:04 <Josh_Soref> Travis: i think i should bring up the background of the Track object instead of a MediaStream
21:04:11 <Josh_Soref> ... we started off trying to record a MediaStream
21:04:13 <mreavy> Josh_Soref: XXXg = MTI formats for recording
21:04:19 <Josh_Soref> ... which is what  sane person would have thought would work
21:04:27 <Josh_Soref> ... after trying to get some data out of a stream
21:04:34 <Josh_Soref> ... you have to face that a MediaStream is mutable
21:04:39 <Josh_Soref> ... tracks can come/go at any time
21:04:47 <Josh_Soref> ... as a recorder, trying to latch onto a media stream
21:05:01 <Josh_Soref> ... you have to specify the behavior of your recorder under all of those changing conditions
21:05:13 <Josh_Soref> ... that's how we ended up specifying a Track level based Recorder
21:05:13 <jesup> q+
21:05:21 <hta> q+
21:05:36 <Josh_Soref> s/Josh_Soref: XXXg = MTI formats for recording//
21:05:38 <Josh_Soref> ack jesup 
21:05:47 <Josh_Soref> jesup: i understand the concern about MediaStream v. Tracks
21:06:07 <Josh_Soref> ... but trying to integrate Tracks and synchronize them seems to be hard
21:06:16 <stefanh> q+
21:06:22 <Josh_Soref> ... for the based non mutating case it seems nice to solve this
21:06:36 <Josh_Soref> Jim_Barnett: if we keep the track level api, you can do the more sophisticated thing with that
21:06:39 <Josh_Soref> ... hta 's suggestion
21:06:50 <Josh_Soref> ... if your format can handle it, great, if not, it gets an error
21:06:57 <Josh_Soref> ... but if we don't have mandatory formats
21:07:06 <Josh_Soref> ... then recorders will behave very differently on different platforms
21:07:07 <Josh_Soref> ack hta 
21:07:13 <Josh_Soref> hta: recordings will be saved
21:07:17 <Josh_Soref> ... for many reasons
21:07:21 <jesup> s/saved/failed/
21:07:29 <Josh_Soref> ... saving because the browser ran out of disk for temporary storage
21:07:31 <jesup> or fail
21:07:50 <Josh_Soref> ... if a recording fails because you ask for something the stream doesn't support
21:07:58 <Josh_Soref> Travis: that's a fair assumption
21:08:06 <Josh_Soref> ... when i discussed Recording with the MS Media Folks
21:08:15 <Josh_Soref> ... they assumed all different Tracks in the Media Stream
21:08:26 <Josh_Soref> ... would be layered into a container format that could be supported
21:08:31 <Josh_Soref> ... they asked for a track limit
21:08:44 <Josh_Soref> ... i said we're going to have only one track
21:09:05 <Josh_Soref> ... but i learned there are container formats that support multiple tracks
21:09:15 <Josh_Soref> ... we can support say 2 tracks and set that as a cap for a recording
21:09:16 <jesup> DVD's (mpeg2-ts I assume) can have N video tracks, and N audio tracks i believe
21:09:28 <Josh_Soref> hta: for a media element, it's specified so tracks can come and go
21:09:29 <gmandyam> q+
21:09:36 <Josh_Soref> jesup: don't they have a content primary track?
21:09:44 <Josh_Soref> hta: they used to, but last i checked, they didn't really
21:09:55 <jesup> s/hta/stefan/
21:09:55 <Josh_Soref> ... for recorder, you should record all media tracks
21:10:05 <Josh_Soref> s/jesup/Jim_Barnett/
21:10:13 <Josh_Soref> Jim_Barnett: so for recorder, it should try to record everything
21:10:21 <Josh_Soref> ... and then have it throw if it fails?
21:10:42 <Josh_Soref> ... for more complicated recording, you'd have to pull the data out into your own object and record that
21:10:52 <stefanh> ack me
21:10:53 <Josh_Soref> s/hta:/stefanh:/
21:11:07 <Josh_Soref> Jim_Barnett: if we make them the same interface, it simplifies things
21:11:25 <Josh_Soref> gmandyam: it looks like w8 was the inspiration for this
21:11:40 <Josh_Soref> ... the android api allows for setting an audio interface and a video interface
21:11:43 <Josh_Soref> ... why didn't you just do that?
21:11:52 <Josh_Soref> Jim_Barnett: the track by track basis
21:12:00 <Josh_Soref> ... for media applications, you need access to just one track
21:12:04 <hta> Android media recorder: http://developer.android.com/reference/android/media/MediaRecorder.html
21:12:09 <Josh_Soref> ... for video tracking, you need just the video
21:12:18 <adambe> q?
21:12:19 <jesup> If you need to work on a single track, create a derivative MediaStream with one track
21:12:20 <Josh_Soref> ... for speech recognition, you need just the audio track
21:12:24 <Josh_Soref> ack gmandyam 
21:12:25 <adambe> q+
21:12:53 <jesup> MediaStream Processing API :-)
21:12:56 <Josh_Soref> gmandyam: i don't know XXq
21:13:05 <Josh_Soref> Jim_Barnett: there's no way to access video/media in their own format
21:13:17 <Josh_Soref> ... we need an api to ask for media in a known format
21:13:35 <Josh_Soref> Travis: why do we latch onto MediaStream/Track v. a standalone recorder?
21:13:38 <Josh_Soref> gmandyam: yep
21:13:42 <Josh_Soref> ack adambe 
21:13:44 <Josh_Soref> adambe: 
21:13:49 <Josh_Soref> s/adambe: //
21:13:55 <Josh_Soref> adambe: say you have a media stream
21:13:59 <Josh_Soref> ... it has a video track playing
21:14:04 <Josh_Soref> ... and another video track playing
21:14:13 <Josh_Soref> ... do you expect to have 2 media tracks?
21:14:24 <Josh_Soref> ... suddenly the content is switched
21:14:44 <Josh_Soref> Travis: we don't know
21:14:50 <Josh_Soref> ... and they're complicated problems to figure out
21:15:01 <Josh_Soref> Jim_Barnett: there's very little structure to Media Streams/Tracks
21:15:08 <Josh_Soref> ... you could try to assume there's a primary track
21:15:16 <Josh_Soref> ... but that may work for some cases, but not others
21:15:22 <Josh_Soref> s/playing/starts playing/
21:15:32 <Josh_Soref> Jim_Barnett: that's a reason to have a low level api 
21:15:40 <Josh_Soref> adambe: say there's a conference
21:15:44 <Josh_Soref> ... and one pair records the conference
21:15:54 <Josh_Soref> ... a viewer might want to be able to switch between the different participants
21:16:06 <Josh_Soref> ... recording a stream is exactly as it'd look in a video element
21:16:13 <Josh_Soref> ... the resulting thing
21:16:22 <Josh_Soref> Jim_Barnett: if a viewer could switch during playback
21:16:28 <Josh_Soref> ... you'd include all in the file
21:16:31 <stefanh> agree to Jim
21:16:32 <Josh_Soref> ... and the viewer would choose
21:16:44 <Josh_Soref> adambe: while that's neat
21:16:57 <jesup> stefan is correct
21:17:00 <Josh_Soref> ... i think that it's more reasonable to just record the visible track
21:17:08 <Josh_Soref> Jim_Barnett: you could have a MediaStream where it has 4 Tracks
21:17:13 <Josh_Soref> ... each of which is being displayed
21:17:23 <Josh_Soref> Travis: we could think of the recorder as a Destination for a MediaStream
21:17:28 <Josh_Soref> ... instead of part of the Pipeline
21:17:42 <Josh_Soref> ... the Recorder could build a notion of a primary track
21:17:47 <Josh_Soref> ... putting the control into the application
21:17:56 <Josh_Soref> ... getting away from the view of the application
21:18:07 <Josh_Soref> stefanh: you might want to look at the Web Audio API proposal
21:18:16 <Josh_Soref> ... it's implemented in Chrome on Mac
21:18:25 <Josh_Soref> ... there you can get Audio from a MediaStream track
21:18:34 <Josh_Soref> ... i think that's implemented as a destination
21:18:34 <hta> s/stefanh/hta
21:18:46 <Josh_Soref> adambe: we have the notion of enabled/disabled tracks in a stream
21:18:52 <Josh_Soref> ... but i think we're moving away from that
21:19:24 <Josh_Soref> hta: the proposal has gotten a deal of feedback. we'll take it to the list
21:19:32 <Josh_Soref> Topic: Direct assignment
21:19:43 <Josh_Soref> hta: createURL()
21:19:56 <Josh_Soref> ... instead of doing that on the video source
21:20:01 <Josh_Soref> ... we have an attribute on the <video>
21:20:12 <Josh_Soref> anant: roc has posted to the list
21:20:22 <Josh_Soref> ... we're not excited about using URLs to represent a MediaStream
21:20:27 <Josh_Soref> ... for many reasons as noted on the list
21:20:48 <Josh_Soref> ... adam bart has pointed out XXm
21:20:53 <Josh_Soref> ... so there's a compromise
21:21:01 <Josh_Soref> ... it's also easy for the developer to grok
21:21:13 <Josh_Soref> ... i don't see advantages to representing Media Stream as a URL
21:21:16 <hta> s/XXm/the many reasons why assignment to src of anything but an URL is a bad idea/
21:21:23 <jesup> This is available now in Mozilla Nightly and soon Aurora as video.mozSrcObject = stream
21:21:25 <dom> q+
21:21:33 <Josh_Soref> ... it adds a new element to a spec outside our groups
21:21:42 <Josh_Soref> s/groups/group's specification domain/
21:22:00 <Josh_Soref> ... our proposal is to not support URLs at all
21:22:04 <Josh_Soref> ... there are lifetime issues
21:22:14 <Josh_Soref> ... you have to come up with a new url prefix
21:22:16 <Josh_Soref> ... which is icky
21:22:24 <Josh_Soref> adambe: any version of direct assigning
21:22:31 <Josh_Soref> ... will require some changes to the <video> element
21:22:37 <dom> ack me
21:22:37 <Josh_Soref> ack dom 
21:22:57 <Josh_Soref> dom: if it's just adding a new attribute to the  <video> element interface
21:23:02 <stefanh> guess it is the media element
21:23:04 <Josh_Soref> ... we could define it as a supplemental interface
21:23:11 <Josh_Soref> ... using the WebIDL partial interface {}
21:23:23 <Josh_Soref> ... if we need to specify how video.src is handled
21:23:28 <Josh_Soref> ... we'd probably need to coordinate with HTML WG
21:23:44 <Josh_Soref> stefanh: maybe we don't need to change the src attribute
21:24:01 <Josh_Soref> ... but we'd need to define what happens if you have video.src and then do video.somethingElse =
21:24:14 <Josh_Soref> anant: i think we can define all those behaviors in the partial interface
21:24:29 <Josh_Soref> dom: i think we should try to do something on our
21:24:31 <Josh_Soref> ... own
21:24:37 <Josh_Soref> ... but we should coordinate with them
21:24:54 <Josh_Soref> Zakim, mute dom
21:24:54 <Zakim> dom should now be muted
21:25:07 <Josh_Soref> stefanh: i'll assign an action to anant 
21:25:15 <hta> action anant: write up proposal for srcObject
21:25:15 <anant> s/stefanh/hta
21:25:16 <trackbot> Created ACTION-11 - Write up proposal for srcObject [on Anant Narayanan - due 2012-10-16].
21:25:47 <Josh_Soref> Topic  AOB
21:25:53 <Josh_Soref> s/Topic/Topic:/
21:26:07 <Josh_Soref> adambe: is this the last tel-conf before tpac?
21:26:09 <Josh_Soref> hta: yes
21:26:13 <Josh_Soref> adambe: see everyone there
21:26:22 <adambe> s/adambe/anant/
21:26:31 <Josh_Soref> s/adambe/anant/
21:26:38 <hta> action anant: Send a proposal about device enumeration.
21:26:38 <trackbot> Created ACTION-12 - Send a proposal about device enumeration. [on Anant Narayanan - due 2012-10-16].
21:27:03 <Josh_Soref> hta: thanks Josh_Soref for scribing
21:27:09 <Josh_Soref> Josh_Soref: see everyone at TPAC
21:27:26 <Josh_Soref> trackbot, end meeting
21:27:26 <trackbot> Zakim, list attendees
21:27:26 <Zakim> As of this point the attendees have been +46.1.07.14.aaaa, +1.650.241.aabb, +91.22.39.14.aacc, [Microsoft], +1.289.261.aadd, +1.610.889.aaee, +1.858.651.aaff, Jim_Barnett,
21:27:29 <Zakim> ... +46.1.07.14.aagg, [Mozilla], Josh_Soref, stefanh, gmandyam, jesup, hta, dom
21:27:29 <Zakim> -dom
21:27:29 <Zakim> -gmandyam
21:27:29 <Zakim> -[Mozilla]
21:27:31 <jesup> Josh_Soref: ++
21:27:31 <Zakim> - +46.1.07.14.aagg
21:27:31 <Zakim> -stefanh
21:27:33 <Zakim> -[Microsoft]
21:27:34 <Zakim> -Jim_Barnett
21:27:34 <trackbot> RRSAgent, please draft minutes
21:27:35 <RRSAgent> I have made the request to generate http://www.w3.org/2012/10/09-mediacap-minutes.html trackbot
21:27:36 <trackbot> RRSAgent, bye
21:27:36 <RRSAgent> I see 3 open action items saved in http://www.w3.org/2012/10/09-mediacap-actions.rdf :
21:27:36 <RRSAgent> ACTION: dom to clarify W3C position on fingerprinting [1]
21:27:36 <RRSAgent>   recorded in http://www.w3.org/2012/10/09-mediacap-irc#T20-46-04
21:27:36 <RRSAgent> ACTION: anant to write up proposal for srcObject [2]
21:27:36 <RRSAgent>   recorded in http://www.w3.org/2012/10/09-mediacap-irc#T21-25-15
21:27:36 <RRSAgent> ACTION: anant to Send a proposal about device enumeration. [3]
21:27:36 <RRSAgent>   recorded in http://www.w3.org/2012/10/09-mediacap-irc#T21-26-38
21:27:37 <Zakim> -Josh_Soref
21:27:39 <Zakim> -jesup
21:27:42 <adambe> adambe has left #mediacap
21:27:47 <Zakim> -hta