14:45:39 <RRSAgent> RRSAgent has joined #mediacap
14:45:39 <RRSAgent> logging to http://www.w3.org/2012/08/23-mediacap-irc
14:45:41 <trackbot> RRSAgent, make logs public
14:45:41 <Zakim> Zakim has joined #mediacap
14:45:43 <trackbot> Zakim, this will be MCAP
14:45:43 <Zakim> ok, trackbot; I see UW_Web RTC(MediaCap)11:00AM scheduled to start in 15 minutes
14:45:44 <trackbot> Meeting: Media Capture Task Force Teleconference
14:45:44 <trackbot> Date: 23 August 2012
14:46:10 <Zakim> UW_Web RTC(MediaCap)11:00AM has now started
14:46:17 <Zakim> +??P0
14:47:09 <Zakim> +??P4
14:48:55 <DanD> DanD has joined #mediacap
14:49:04 <Zakim> -??P4
14:49:19 <gaowenmei> gaowenmei has joined #mediacap
14:50:08 <Zakim> +??P4
14:50:26 <Zakim> +Dan_Druta
14:51:01 <Zakim> -Dan_Druta
14:51:44 <Josh_Soref> Zakim, code?
14:51:44 <Zakim> the conference code is 6227 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), Josh_Soref
14:52:01 <Josh_Soref> Scribe: Josh_Soref
14:52:15 <Zakim> +??P16
14:52:27 <Josh_Soref> Zakim, who is making noise?
14:52:37 <Zakim> Josh_Soref, listening for 10 seconds I heard sound from the following: ??P16 (100%)
14:52:46 <Josh_Soref> Zakim, P16 is me
14:52:46 <Zakim> sorry, Josh_Soref, I do not recognize a party named 'P16'
14:52:49 <Josh_Soref> Zakim, ??P16 is me
14:52:49 <Zakim> +Josh_Soref; got it
14:52:55 <fluffy> fluffy has joined #mediacap
14:53:15 <Josh_Soref> Zakim, mute me
14:53:15 <Zakim> Josh_Soref should now be muted
14:53:23 <Josh_Soref> Zakim, draft minutes
14:53:23 <Zakim> I don't understand 'draft minutes', Josh_Soref
14:53:28 <Josh_Soref> RRSAgent, draft minutes
14:53:28 <RRSAgent> I have made the request to generate http://www.w3.org/2012/08/23-mediacap-minutes.html Josh_Soref
14:53:32 <Zakim> + +1.408.902.aaaa
14:53:57 <Josh_Soref> Zakim, where is +1408?
14:53:57 <Zakim> North American dialing code 1.408 is California
14:55:19 <Josh_Soref> Agenda: http://lists.w3.org/Archives/Public/public-media-capture/2012Aug/0053.html
14:55:20 <stefanh> stefanh has joined #mediacap
14:55:23 <Josh_Soref> RRSAgent, draft minutes
14:55:23 <RRSAgent> I have made the request to generate http://www.w3.org/2012/08/23-mediacap-minutes.html Josh_Soref
14:55:32 <fluffy> Zakim, aaaa is fluffy
14:55:32 <Zakim> +fluffy; got it
14:55:34 <wyh> wyh has joined #mediacap
14:56:17 <Josh_Soref> Topic: Minutes Approval
14:56:25 <stefanh> agenda and stuff: http://lists.w3.org/Archives/Public/public-media-capture/2012Aug/0053.html
14:56:38 <Zakim> + +1.650.241.aabb
14:56:39 <yahui> yahui has joined #mediacap
14:56:44 <Josh_Soref> s|agenda and stuff: http://lists.w3.org/Archives/Public/public-media-capture/2012Aug/0053.html||
14:56:54 <burn> burn has joined #mediacap
14:56:56 <Jim_Barnett> Jim_Barnett has joined #mediacap
14:56:59 <neilstratford> neilstratford has joined #mediacap
14:57:17 <hta> hta has joined #mediacap
14:57:30 <fluffy> Zakim, who is here?
14:57:30 <Zakim> On the phone I see ??P0, ??P4, Josh_Soref (muted), fluffy, +1.650.241.aabb
14:57:32 <Zakim> On IRC I see hta, neilstratford, Jim_Barnett, burn, yahui, stefanh, fluffy, gaowenmei, Zakim, RRSAgent, Josh_Soref, richt, derf, trackbot, dom
14:57:42 <Zakim> + +1.407.835.aacc
14:57:53 <hta> zakim, aabb is me
14:57:53 <Zakim> +hta; got it
14:57:58 <burn> zakim, aacc is Dan_Burnett
14:57:58 <Zakim> +Dan_Burnett; got it
14:58:10 <burn> zakim, I am Dan_Burnett
14:58:10 <Zakim> ok, burn, I now associate you with Dan_Burnett
14:58:24 <adambe> adambe has joined #mediacap
14:58:31 <Zakim> + +46.1.07.14.aadd
14:58:41 <hta> zakim, I am Harald_Alvestrand
14:58:41 <Zakim> sorry, hta, I do not see a party named 'Harald_Alvestrand'
14:58:42 <stefanh> zakim, aadd is me
14:58:42 <Zakim> +stefanh; got it
14:58:54 <Josh_Soref> Chair: Stefan_Hakansson, Harald_Alvestrand
14:58:55 <Zakim> + +46.1.07.14.aaee
14:59:18 <stefanh> zakim, aaee is adambe
14:59:18 <Zakim> +adambe; got it
15:00:07 <Josh_Soref> Zakim, who is on the call?
15:00:10 <Zakim> On the phone I see ??P0, ??P4, Josh_Soref (muted), fluffy, hta, Dan_Burnett, stefanh, adambe
15:00:25 <Milan_> Milan_ has joined #Mediacap
15:00:32 <Zakim> +[Mozilla]
15:00:32 <gaowenmei> gaowenmei or yahui
15:00:59 <dom> Zakim, call dom-mobile
15:00:59 <Zakim> ok, dom; the call is being made
15:01:00 <derf> Zakim, [Mozilla] contains me
15:01:00 <Zakim> +Dom
15:01:00 <Zakim> +derf; got it
15:01:06 <Zakim> +Jim_Barnett
15:01:27 <Zakim> +gmandyam
15:01:42 <Josh_Soref> Zakim, who is making noise?
15:01:54 <Zakim> Josh_Soref, listening for 10 seconds I heard sound from the following: ??P0 (35%), hta (37%), stefanh (13%), Jim_Barnett (5%)
15:02:03 <Josh_Soref> Zakim, ??p0 is gaowenmei 
15:02:04 <Zakim> +gaowenmei; got it
15:02:13 <Josh_Soref> Zakim, mute gaowenmei 
15:02:19 <Zakim> gaowenmei should now be muted
15:02:28 <Josh_Soref> Zakim, unmute gaowenmei 
15:02:30 <Zakim> gaowenmei should no longer be muted
15:02:34 <Josh_Soref> Zakim, unmut eme
15:02:36 <Josh_Soref> Zakim, unmute me
15:02:38 <Zakim> I don't understand 'unmut eme', Josh_Soref
15:02:39 <richt_> richt_ has joined #mediacap
15:02:40 <Zakim> Josh_Soref should no longer be muted
15:02:57 <Josh_Soref> Zakim, ??p4 is yahui
15:02:57 <Zakim> +yahui; got it
15:03:02 <Josh_Soref> Zakim, who is on the call?
15:03:02 <Zakim> On the phone I see gaowenmei, yahui, Josh_Soref, fluffy, hta, Dan_Burnett, stefanh, adambe, [Mozilla], Dom, Jim_Barnett, gmandyam
15:03:05 <Zakim> [Mozilla] has derf
15:03:45 <Milan_> What is the number to dial in?
15:03:46 <Zakim> +[Microsoft]
15:03:53 <Josh_Soref> Zakim, code?
15:03:53 <Zakim> the conference code is 6227 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), Josh_Soref
15:04:08 <Josh_Soref> Zakim, [Microsoft] is Travis
15:04:08 <Zakim> +Travis; got it
15:04:25 <TravisLeithead> TravisLeithead has joined #mediacap
15:04:36 <TravisLeithead> Present+ Travis_Leithead
15:04:42 <Zakim> +richt_
15:04:42 <Josh_Soref> stefanh: minutes approval...
15:04:48 <Josh_Soref> ... does anyone object to approving the minutes?
15:04:50 <Zakim> +Milan_Young
15:04:55 <TravisLeithead> zakim, who is on the call
15:04:58 <Josh_Soref> [ silence ]
15:05:06 <Josh_Soref> RESOLUTION: Approve minutes from previous conference
15:05:08 <Zakim> I don't understand 'who is on the call', TravisLeithead
15:05:17 <Josh_Soref> RRSAgent, draft minutes
15:05:17 <RRSAgent> I have made the request to generate http://www.w3.org/2012/08/23-mediacap-minutes.html Josh_Soref
15:05:31 <Josh_Soref> Topic: Milestones
15:05:51 <Josh_Soref> Zakim, who is on the call?
15:05:51 <Zakim> On the phone I see gaowenmei, yahui, Josh_Soref, fluffy, hta, Dan_Burnett, stefanh, adambe, [Mozilla], Dom, Jim_Barnett, gmandyam, Travis, richt_, Milan_Young
15:05:55 <Zakim> [Mozilla] has derf
15:06:16 <Josh_Soref> stefanh: XX
15:06:18 <Josh_Soref> derf: there's a question about what is the basic functionality
15:06:29 <Josh_Soref> hta: the closest thing we have to the thing on the list
15:06:38 <Josh_Soref> ... is you need to capture things from devices and pass them to media streams
15:06:38 <stefanh> s/derf/fluffy/
15:06:48 <Josh_Soref> ... and you need to pick media streams apart and put them back together
15:06:50 <Josh_Soref> fluffy: that's too big
15:07:00 <Josh_Soref> ... you need to talk about whether you can take data in/out
15:07:01 <dom> s/big/vague
15:07:10 <dom> q+ to ask about input from implementers schedule
15:07:10 <Josh_Soref> hta: access to data was not in the proposal
15:07:13 <Josh_Soref> ... that's recording
15:07:22 <Josh_Soref> stefanh: pushing without security is a no go
15:07:26 <Josh_Soref> ... we can't add security later
15:07:37 <stefanh> s/stefanh/hta/
15:07:47 <Josh_Soref> dom: an important thing about core/not-core
15:07:54 <Josh_Soref> ... is where we can get interop in the short term
15:08:02 <Josh_Soref> ... right now we have two browsers shipping with getUserMedia
15:08:12 <Josh_Soref> ... afaik the interop is limited to setting audio/video to true
15:08:22 <Josh_Soref> ... there isn't interop on assigning media to a <media> element
15:08:31 <Josh_Soref> ... i'm interested in hearing in anyone from Opera
15:08:37 <Josh_Soref> ... or Mozilla/Microsoft/Google
15:08:47 <Josh_Soref> ... about what they think we can get implemented in the coming months
15:09:01 <Josh_Soref> TravisLeithead: for microsoft, i can't comment on upcoming feature set
15:09:08 <Josh_Soref> ... i'm in the game to make sure we have something implementable
15:09:12 <Josh_Soref> ... we've done prototyping in the past
15:09:23 <Josh_Soref> ... i'm interested in hearing what other implementers are up to
15:09:30 <Josh_Soref> ... and keep in mind what we think is best
15:09:43 <Josh_Soref> ... what we have out there is maleable
15:09:52 <Josh_Soref> richt_: what we're shipping at the moment
15:09:56 <Josh_Soref> ... is extremely limited
15:10:04 <Josh_Soref> ... pretty much what you, dom, described
15:10:09 <Josh_Soref> ... we don't comment on upcoming releases
15:10:13 <Josh_Soref> ... our next stage is MediaStream
15:10:22 <Josh_Soref> ... there's no timeline or anything like that, that i can share
15:10:30 <Josh_Soref> ... the next level of the API is MediaStream
15:10:35 <Josh_Soref> ... and the next level after that...
15:11:02 <gmandyam> gmandyam has joined #mediacap
15:11:11 <Josh_Soref> stefanh: Google has getUserMedia, assignment to <media> via a url producing function
15:11:15 <Josh_Soref> ... we have not implemented constraints
15:11:18 <Josh_Soref> ... but we plan to
15:11:39 <stefanh> s/stefanh/hta/
15:11:41 <Josh_Soref> derf: we're similar to Google
15:11:53 <Josh_Soref> ... all of this is hidden behind a pref, because we don't have a security ui yet
15:12:04 <Josh_Soref> ... we're looking at constraints, but i don't think we'll have them in the next few months
15:12:26 <Josh_Soref> dom: should we try to ship core getUserMedia that has just video:true/audio:true, and MediaStream assignment
15:12:43 <Josh_Soref> fluffy: (Cisco), i don't think that meets the needs of the user community
15:12:51 <Josh_Soref> dom: i think it would make it for a large number of users
15:12:59 <Josh_Soref> ... a video stream that you could play with
15:13:08 <Josh_Soref> ... and then we could extend that to add further functionalities
15:13:13 <Josh_Soref> ... this is a straw man suggestion
15:13:22 <Josh_Soref> ... the core that people are agreeing to
15:13:28 <Josh_Soref> ... it might be beneficial to the community
15:13:38 <Josh_Soref> fluffy: i think it'll be hard to figure out how to add stuff in later
15:13:47 <Josh_Soref> ... i don't think you need to figure out the details
15:13:55 <Josh_Soref> ... but you need a structure
15:14:01 <Zakim> -gmandyam
15:14:08 <Josh_Soref> TravisLeithead: having a Recorder is pretty important to our scenarios
15:14:19 <Josh_Soref> derf: fluffy, can you elaborate on what you need to build your applications?
15:14:24 <Josh_Soref> fluffy: camera resolution control
15:14:32 <Zakim> +gmandyam
15:14:33 <Josh_Soref> ... when you have an HD Camera
15:14:45 <Josh_Soref> ... and try to stream 20 channels at 720p
15:14:53 <Josh_Soref> ... you can't do that
15:15:06 <Josh_Soref> ... if i'm on a low bandwidth connection, some ability to pick something lower than that
15:15:13 <Josh_Soref> burn: we have similar needs
15:15:20 <Josh_Soref> ... we need to be able to specify resolution
15:15:27 <Josh_Soref> ... the same thing we've been talking about
15:15:32 <Josh_Soref> ... minimum/maximum framerate
15:15:40 <Josh_Soref> ... if we want to build an application that isn't a toy
15:15:48 <Josh_Soref> dom: if we agree on the core
15:16:00 <Josh_Soref> ... it doesn't mean the features would have to come later
15:16:06 <Josh_Soref> ... a good way to make progress
15:16:12 <Josh_Soref> ... on designing/priorities
15:16:27 <Josh_Soref> ... is to figure out which scenarios/parts of scenarios we want to enable
15:16:38 <dom> s/it doesn't mean/it just means/
15:16:39 <Josh_Soref> fluffy: i find this conversation surreal
15:16:50 <Josh_Soref> ... we did our design requirements
15:16:55 <Josh_Soref> ... our scenarios
15:17:09 <Josh_Soref> ... it seems like we're delaying things by proposing a second/update document
15:17:20 <Josh_Soref> dom: thinking in terms of v1/v2 isn't the right way to think about it
15:17:24 <Josh_Soref> ... think about it as modules
15:17:34 <Josh_Soref> ... the reason we're having this discussion
15:17:40 <Josh_Soref> ... is if we keep adding features and features
15:17:44 <Josh_Soref> ... we're delaying interop
15:17:47 <Josh_Soref> ... on the core piece
15:18:00 <Josh_Soref> ... for as long as we need to discuss peripheral features
15:18:22 <Josh_Soref> ... the reason to discuss this is to try to get an interoperable portion out As Soon As Possible
15:18:27 <Josh_Soref> Zakim, who is making noise?
15:18:38 <Zakim> Josh_Soref, listening for 10 seconds I heard sound from the following: yahui (4%), hta (5%)
15:18:39 <Josh_Soref> fluffy: all of these features were mentioned as a requirement from day 1
15:18:53 <Josh_Soref> derf: there are things that have been in the document for a while
15:19:00 <Josh_Soref> ... we talked about them from the very beginning
15:19:01 <dom> (it's not about being required or not, but being required for ASAP or for later)
15:19:08 <Josh_Soref> ... there have been things discussed more recently
15:19:16 <derf> s/derf/burn/
15:19:21 <Josh_Soref> ... it seems weird to me to look 
15:19:36 <Josh_Soref> ... -- the document has been stable for a month or two
15:19:48 <Josh_Soref> stefanh: we have had some stuff in there for a long time
15:19:53 <Josh_Soref> ... but completely underspecified
15:19:56 <Josh_Soref> ... recording function
15:20:03 <Josh_Soref> burn: not saying it was done
15:20:10 <Josh_Soref> ... just that something that's been in there
15:20:16 <Josh_Soref> ... that a good number of people are interested in
15:20:22 <Josh_Soref> ... we need to finish specifying
15:20:29 <Josh_Soref> ... i'm uncomfortable with yanking things out
15:20:37 <Josh_Soref> ... unless of course they're only a "heading"
15:20:43 <Josh_Soref> derf: i want to second what stefanh said
15:20:52 <Josh_Soref> ... we have an impl in Chrome that throws Exceptions
15:20:58 <Josh_Soref> ... and Firefox calls the Error handler
15:21:04 <Josh_Soref> ... and there's assignment issues
15:21:11 <Josh_Soref> ... these are interop issues we should resolve
15:21:15 <Josh_Soref> ... i think we should prioritize those
15:21:17 <dom> +1 to derf
15:21:19 <Josh_Soref> ... i have no opinion on publishing
15:21:26 <fluffy> +1 derf on we need to fix all that 
15:21:29 <Josh_Soref> ... but we need the underspecified things to be fully specified
15:21:47 <Josh_Soref> Zakim, who is on the call?
15:21:47 <Zakim> On the phone I see gaowenmei (muted), yahui, Josh_Soref, fluffy, hta, Dan_Burnett, stefanh, adambe, [Mozilla], Dom, Jim_Barnett, Travis, richt_, Milan_Young, gmandyam
15:21:50 <Zakim> [Mozilla] has derf
15:22:05 <Josh_Soref> Jim_Barnett: dom suggested splitting things out into modules
15:22:11 <Josh_Soref> ... it doesn't help us make a decision
15:22:17 <Josh_Soref> ... but it lets us release things independently
15:22:21 <Josh_Soref> TravisLeithead: i'm not opposed to that idea
15:22:27 <Josh_Soref> stefanh: i think it's a good idea
15:22:33 <Josh_Soref> hta: seems to make sense
15:22:44 <Josh_Soref> ... that would mean that if we go ahead with a Recording interface
15:22:53 <Josh_Soref> ... we ask someone to put that together as a separate document
15:23:04 <Josh_Soref> Jim_Barnett: i'd be happy to work on that document
15:23:15 <Josh_Soref> dom: if by some miracle we make very quick progress on both modules
15:23:23 <Josh_Soref> ... nothing prevents us from moving them together on the REC track
15:23:30 <Josh_Soref> ... it doesn't delay things
15:23:32 <stefanh> @jim: thanks for offering!
15:23:34 <Josh_Soref> ... but by splitting out work
15:23:40 <Josh_Soref> ... we can guarantee core gets attention
15:23:50 <Josh_Soref> ... and the rest progresses if we have energy/support/resources
15:23:58 <Josh_Soref> ... i think it's a better way to make faster progress
15:24:07 <Josh_Soref> Jim_Barnett: would the constraint language be a candidate for a separate module?
15:24:24 <Josh_Soref> dom: there's been a lot of discussion about constraints and where they fit
15:24:25 <Josh_Soref> q+
15:24:29 <Josh_Soref> ack dom
15:24:29 <Zakim> dom, you wanted to ask about input from implementers schedule
15:25:02 <Josh_Soref> derf: i have no objection to splitting the recording module
15:25:11 <derf> s/derf/fluffy/
15:25:20 <Josh_Soref> ... but constraints as a hook is in core
15:25:35 <Josh_Soref> fluffy: i think the specific constraint names can be defined elsewhere
15:25:39 <Josh_Soref> ... but the constraint api is core
15:25:52 <Josh_Soref> ... unless you have some other mechanism, it's hard to make it optional
15:26:21 <Josh_Soref> dom: it's not the document that becomes the implementation
15:26:35 <Josh_Soref> fluffy: HTML5 spec has a big thing about the <track> element in <video>
15:26:39 <Josh_Soref> ... we don't implement it
15:26:51 <Josh_Soref> ... even if you don't modularize things, we will
15:26:54 <dom> s/fluffy/derf/
15:27:09 <Josh_Soref> stefanh: seems we agreed to split out recording
15:27:20 <Josh_Soref> ... and we could integrate later depending on progress
15:27:21 <gmandyam> +q
15:27:34 <Josh_Soref> Jim_Barnett: are we taking TravisLeithead's proposal as a basis?
15:27:44 <Josh_Soref> TravisLeithead: i think my old proposal needs some work
15:27:52 <Josh_Soref> ... if we want to use that, i'd like to do a revised edition of that
15:27:58 <Josh_Soref> ... but if someone else would like to help
15:28:05 <Josh_Soref> ... i'm open to collaboration
15:28:07 <Josh_Soref> Jim_Barnett: i'm glad to help
15:28:19 <Josh_Soref> stefanh: ok, Jim_Barnett + TravisLeithead will start working on that document
15:28:22 <Josh_Soref> q?
15:28:36 <Josh_Soref> q- Jim_Barnett 
15:28:39 <Josh_Soref> q- Josh_Soref 
15:28:55 <Josh_Soref> Topic: Scenarios/Requirements Document
15:29:15 <Josh_Soref> burn: one question came up is standardizing on "Recording" or "Media Capture" as a term
15:29:21 <Josh_Soref> ... there's a list of "sort of requirements"
15:29:27 <gmandyam> Will still image capture be part of the recording module spec?
15:29:29 <Josh_Soref> ... browser requires permissions
15:29:45 <Josh_Soref> ... do we want to take it out/or fold it into requirements
15:29:59 <TravisLeithead> The document we're discussing is here: http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html
15:30:00 <Josh_Soref> ... in sec 5, we'll have a scenarios and apis, and that section could go away
15:30:14 <Josh_Soref> ... then do we want to go through stefanh 's comments
15:30:21 <Josh_Soref> hta: Media Capture v. Recording
15:30:37 <Josh_Soref> ... we're best off if we use Recording as the act of putting media into a form that can be stored
15:30:40 <stefanh> +1 to hta
15:30:46 <Josh_Soref> ... whereas Media Capture, is anything that gets media into the computer
15:30:57 <Josh_Soref> stefanh: i'd suggest adding a definitions section early
15:31:00 <TravisLeithead> Definitions: http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html#concepts-and-definitions
15:31:11 <Josh_Soref> Jim_Barnett: i'll do that
15:31:22 <Josh_Soref> ... we thought of a case of speech recognition
15:31:29 <Josh_Soref> ... is that recording or capture?
15:31:37 <Josh_Soref> hta: i'd call it recording
15:31:41 <Josh_Soref> TravisLeithead: i'd agree with that
15:31:47 <stefanh> me too!
15:31:47 <Josh_Soref> Jim_Barnett: ok, great, i can use that as an example
15:31:53 <Josh_Soref> ... section 5?
15:31:56 <Josh_Soref> ... opinions?
15:32:13 <Josh_Soref> ... streams, reinitialization, stopping devices,
15:32:23 <Josh_Soref> ... how things might work, but not something for a final scenarios documnt
15:32:25 <Josh_Soref> TravisLeithead: i agree
15:32:31 <Josh_Soref> ... a lot of those i put forth early on
15:32:36 <Josh_Soref> ... and we've clarified them
15:32:46 <Josh_Soref> ... some which we clearly understand, should be stated as such
15:33:06 <Josh_Soref> ... having things in this document is interesting from a historical document
15:33:22 <Josh_Soref> Jim_Barnett: some of these we should figure out to remove
15:33:29 <Josh_Soref> ... and the rest, we can move into a bug tracker
15:33:38 <Josh_Soref> ... i can do this on the list
15:33:51 <Josh_Soref> ... the last one, section 2, has things that sound like requirements
15:33:59 <Josh_Soref> ... should those go out / get folded into reqiurements?
15:34:06 <Josh_Soref> TravisLeithead: i'd like to see them folded into requirements
15:34:16 <Josh_Soref> ... or a discussion on the list to remove them
15:34:25 <Josh_Soref> Jim_Barnett: i used them to create requirements
15:34:30 <Josh_Soref> TravisLeithead: if there's duplicates, we can remove them
15:34:34 <Josh_Soref> Jim_Barnett: i'll go through them
15:34:40 <Josh_Soref> ... and figure out which ones are orphans
15:34:50 <Josh_Soref> hta: as soon as requirements in the same section covers everything in the list
15:34:53 <Josh_Soref> ... i think the list should go away
15:34:59 <Josh_Soref> Jim_Barnett: i'm going to go through it and check
15:35:06 <Josh_Soref> ... whatever's left, we can discuss on the ML
15:35:14 <Josh_Soref> ... do we have time to go through stefanh 's comments?
15:35:17 <Josh_Soref> stefanh: i think we have time
15:35:26 <Josh_Soref> ... but maybe it's best to give people time to read
15:35:31 <Josh_Soref> Jim_Barnett: that's what i was thinking
15:35:37 <Josh_Soref> ... give people time to read and pursue on the list
15:35:48 <Josh_Soref> Jim_Barnett: a lot of scenarios refer to previewing remote media
15:35:55 <Josh_Soref> ... if this is a requirements document for local media
15:36:02 <Josh_Soref> ... why are they here?
15:36:09 <Josh_Soref> stefanh: they're UCs for
15:36:19 <Josh_Soref> hta: maybe the scenarios should be removed/modified
15:36:24 <Josh_Soref> Jim_Barnett: the scenarios are good
15:36:30 <Josh_Soref> ... but they have referenced to remote media
15:36:35 <Josh_Soref> TravisLeithead: when i was putting this together
15:36:48 <Josh_Soref> ... i believe i was instructed to have it apply to both WebRTC's document and getUserMedia
15:36:56 <Josh_Soref> ... so the scenarios intermingle local+remote
15:37:09 <Josh_Soref> ... if we want to scope this down, there's some surgery required for the scenarios
15:37:21 <Josh_Soref> Jim_Barnett: or could we point to the the webrtc doc?
15:37:34 <Josh_Soref> hta: in an ideal world
15:37:51 <Josh_Soref> ... for each requirement here, the RTCWeb requirement number
15:38:01 <Josh_Soref> ... we should be able to say "this is already done over there"
15:38:04 <Josh_Soref> Jim_Barnett: i can do that
15:38:09 <Josh_Soref> hta: if they don't match up, we have a problem
15:38:20 <Josh_Soref> TravisLeithead: is there another requirement for WebRTC
15:38:25 <Josh_Soref> ... not IETF RTCWeb
15:38:36 <Josh_Soref> hta: we're using the RTCWeb requirements document as a joint requirement
15:38:41 <Josh_Soref> ... stefanh is the editor
15:38:45 <Josh_Soref> ... so claiming it's an IETF document
15:38:49 <Josh_Soref> ... it's hard to tell which is which
15:38:52 <Josh_Soref> TravisLeithead: alright
15:39:06 <Josh_Soref> ... i think it's a good exercise to say which aren't handled by the gUM spec we're producing
15:39:19 <Josh_Soref> Jim_Barnett: if there isn't a separate WebRTC requirement document
15:39:22 <Josh_Soref> ... where do i go?
15:39:28 <Josh_Soref> hta:  you reference the IETF document
15:39:38 <Josh_Soref> stefanh: i'm not sure how lucky you'll be in that exercise
15:39:47 <Josh_Soref> ... i'm not sure you'll be able to find a 1:1 mapping
15:39:51 <Josh_Soref> TravisLeithead: that was my concern
15:39:55 <Josh_Soref> ... but, go for it Jim_Barnett 
15:39:59 <Josh_Soref> Jim_Barnett: let me see what i can do
15:40:04 <Josh_Soref> ... maybe i refer to a couple of documents
15:40:13 <Josh_Soref> ... plus some scotch tape and glue over here
15:40:19 <Josh_Soref> stefanh: let's see where it ends up
15:40:30 <Josh_Soref> ... i wouldn't object to keep the requirements there
15:40:40 <Josh_Soref> Jim_Barnett: i think the idea is to add a pointer to the RTCWeb Requirements document
15:40:46 <Josh_Soref> stefanh: if you need help, i can help
15:40:49 <Josh_Soref> Jim_Barnett: ok, thanks
15:41:08 <Josh_Soref> Topic: Constraints modification API proposal from Travis
15:41:27 <TravisLeithead> Revised Constraints API Proposal (start of thread): http://lists.w3.org/Archives/Public/public-media-capture/2012Aug/0066.html
15:41:31 <Josh_Soref> hta: we had a very busy few hours on the ML
15:41:44 <Josh_Soref> ... somehow, TravisLeithead has now come with a revised proposal
15:41:49 <Josh_Soref> ... that seems to make my life much more complicated
15:41:52 <Josh_Soref> ... i'm not so happy
15:41:58 <Josh_Soref> ... one thing that has come up
15:42:04 <Josh_Soref> ... is whether tracks are mutable or immutable
15:42:13 <Josh_Soref> ... another question is how do we represent device manipulation
15:42:33 <Josh_Soref> ... "turn camera left", "turn on flash"
15:42:50 <Josh_Soref> ... one thing we _assumed_ in WebRTC land
15:42:55 <Josh_Soref> Zakim, who is making noise?
15:43:07 <Zakim> Josh_Soref, listening for 10 seconds I heard sound from the following: hta (36%)
15:43:08 <Josh_Soref> Zakim, mute dom 
15:43:09 <Zakim> Dom should now be muted
15:43:35 <Josh_Soref> ... the WebRTC pattern seems to me
15:43:46 <Josh_Soref> ... lining up tracks/streams is a very heavyweight operation
15:43:52 <Josh_Soref> ... involving interchanges between parties
15:44:02 <Josh_Soref> ... to handle changes between parties
15:44:09 <Josh_Soref> ... that has to be modeled as a change to a track
15:44:15 <Josh_Soref> ... that has interesting consequences
15:44:21 <Josh_Soref> ... new singaling
15:44:26 <Josh_Soref> s/sing/sign/
15:44:42 <Josh_Soref> ... i'd like to see if we can get constraints that are changes to a track
15:44:55 <Josh_Soref> ... but i have a requirement to change the resolution of video while the video is playing
15:45:03 <Josh_Soref> ... that's a definite requirement (speaking as Google)
15:45:16 <Josh_Soref> TravisLeithead: i think your thoughts are shared by the majority of those (everyone?) who replied to the proposal
15:45:26 <Josh_Soref> ... i'm not married to the concept of immutable tracks
15:45:30 <Josh_Soref> ... given the input you provided
15:45:39 <Josh_Soref> ... i'm more than happy to do a second version
15:45:52 <Josh_Soref> ... where constraints on tracks change the contents of the existing tracks
15:46:03 <Josh_Soref> ... i think it's been shown on the ML how swapping out tracks is too complicated
15:46:12 <Josh_Soref> ... i'm in agreement on that
15:46:19 <Josh_Soref> hta: we have a point on the agenda about track controls
15:46:29 <Josh_Soref> ... richt_ do you see a relationship between that and this discussion?
15:46:46 <Josh_Soref> TravisLeithead: i'm not sure what you're referring to
15:46:50 <Josh_Soref> ... can you be more specific
15:46:57 <Josh_Soref> hta: i saw a proposal from you for a change-track
15:47:05 <Josh_Soref> ... i didn't quite understand where you were going with it
15:47:19 <Josh_Soref> ... if you had an idea of how we should approach constraints modification
15:47:22 <Josh_Soref> ... i'd appreciate it now
15:47:29 <Josh_Soref> TravisLeithead: let me provide a high level proposal
15:47:55 <Josh_Soref> ... the proposal at its heart has a couple of fundamental changes
15:48:03 <Josh_Soref> ... the notable change is that it introduces a new list
15:48:13 <Josh_Soref> ... currently MediaStreams have a list that contains Tracks
15:48:20 <Josh_Soref> ... two lists, and Audio Tracks list and a Video Tracks list
15:48:25 <Josh_Soref> ... what i proposed is two additional lists
15:48:34 <Josh_Soref> ... present only on local media stream objects
15:48:41 <Josh_Soref> ... corresponding to the devices providing local media
15:48:57 <Josh_Soref> ... the reason i've done that is that the current lists
15:49:04 <Josh_Soref> ... can have things removed/inserted
15:49:22 <Josh_Soref> ... which makes it hard to identify which streams "I'm generating"
15:49:26 <Josh_Soref> ... and which are remote
15:49:39 <Josh_Soref> ... so these two additional lists are "my active local devices"
15:49:47 <richt_> q+
15:49:52 <Josh_Soref> q- gmandyam 
15:50:04 <Josh_Soref> ... if i call gUM, the selected source will be in that list
15:50:15 <Josh_Soref> q+ to ask if an item will go away when the user closes the device source
15:50:30 <Josh_Soref> ... on top of that, i've added an api to get current settings for a track
15:50:35 <Josh_Soref> ... this works with constraints
15:50:43 <Josh_Soref> ... and it gives a list of constraint ranges
15:50:48 <Josh_Soref> ... white balance -1...+1
15:50:54 <Josh_Soref> ... min-video x...y
15:51:05 <Josh_Soref> ... so you can extract those from one of these tracks
15:51:12 <Josh_Soref> ... and apply decision logic based on the end result
15:51:20 <Josh_Soref> ... if you want the lowest resolution from the camera
15:51:26 <Josh_Soref> ... if you're streaming a lot of video
15:51:30 <Josh_Soref> ... once you've figured this out
15:51:34 <Josh_Soref> ... you apply that to the track
15:51:38 <Josh_Soref> ... and that changes the track
15:51:47 <Josh_Soref> ... this is bolted onto the local track list
15:51:54 <Josh_Soref> ... so you can't use it on remote peer streams
15:51:58 <Josh_Soref> ... that's the high level proposal
15:52:02 <Josh_Soref> ... what we spoke of previously
15:52:09 <Josh_Soref> ... when you applied a constraint to a track
15:52:14 <Josh_Soref> ... it might cause a track to be stopped
15:52:19 <Josh_Soref> ... and a new track created
15:52:22 <Josh_Soref> ... the feedback i got
15:52:28 <Josh_Soref> ... was that was very heavy for UAs
15:52:32 <Josh_Soref> ... the general feedback was
15:52:39 <Josh_Soref> ... let's not dispose of the track and create a new track
15:52:49 <Josh_Soref> ... let's just modify the existing track
15:52:52 <Josh_Soref> ... i'm not opposed to that
15:52:59 <Josh_Soref> ... when you apply changes to a track
15:53:09 <Josh_Soref> ... perhaps an event is fired
15:53:12 <Josh_Soref> ... and that's it
15:53:15 <Josh_Soref> ack richt_ 
15:53:24 <burn> q+
15:53:53 <Josh_Soref> richt_: one thing i wanted was to highlight differences
15:54:00 <Josh_Soref> ... between TravisLeithead 's proposal and our proposal
15:54:11 <Josh_Soref> ... one goal is to apply changes best effort
15:54:18 <Josh_Soref> ... after a resource is available
15:54:32 <Josh_Soref> ... our api isn't specific to a local video/camera stream track
15:54:40 <Josh_Soref> ... we're using instead is a concept of a locked object
15:54:45 <Josh_Soref> ... the interface will be available
15:54:54 <Josh_Soref> ... but it won't work for locked objects
15:55:07 <Josh_Soref> ... TravisLeithead 's proposal adds an extra list of objects
15:55:13 <Josh_Soref> ... objects with different methods
15:55:17 <Josh_Soref> ... what we're proposing
15:55:26 <Josh_Soref> ... is to add the methods to all objects
15:55:36 <Josh_Soref> ... which reduces the object count
15:55:45 <Josh_Soref> hta: one thing i got from the discussion
15:55:53 <Josh_Soref> ... trying to set a constraint has to be able to fail
15:56:03 <Josh_Soref> ... people will try to apply constraints to an object that won't work
15:56:07 <Josh_Soref> ... for various reasons
15:56:14 <Josh_Soref> burn: i want to jump in on constraints
15:56:32 <Josh_Soref> ... as one of the people who sent the first email on it
15:56:39 <Josh_Soref> ... constraints were originally designed for selection
15:56:42 <Josh_Soref> ... not control over tracks
15:56:55 <Josh_Soref> ... the selection piece was what a developer would want to do when they want to get media
15:57:00 <Josh_Soref> ... and they want media for their purposes
15:57:05 <Josh_Soref> ... constraints are "things i'd like to have"
15:57:14 <Josh_Soref> ... or "these i must have, or there's no point"
15:57:16 <Josh_Soref> ... once you have that
15:57:25 <Josh_Soref> ... it seems like it'd make sense to look at a different api
15:57:31 <Josh_Soref> ... to figure out detailed capabilities
15:57:35 <Josh_Soref> ... or figure out how to control it
15:57:43 <Josh_Soref> ... i just wanted to clarify that
15:57:51 <Josh_Soref> ... conceptually that doesn't make sense to me
15:58:01 <Josh_Soref> adambe: i've thought about constraints / control
15:58:13 <Josh_Soref> ... i agree with hta that a control api is better suited as a set of methods
15:58:23 <Josh_Soref> ... than perhaps a huge constraint object
15:58:34 <Josh_Soref> ... jesup has proposed wanting to change a Track down the line
15:58:43 <Josh_Soref> ... when you have random access to it
15:58:55 <Josh_Soref> ... you really need a method for selecting a track in an advanced way
15:59:03 <Josh_Soref> s/you/Do you/
15:59:07 <Josh_Soref> ... and another api to change things
15:59:17 <Josh_Soref> ... only going with Constraints makes it possible to select
15:59:28 <Josh_Soref> ... but going with Change lets you do more modifications at a later point
15:59:30 <fluffy> q+
15:59:34 <Josh_Soref> ... having an API to change streams
15:59:40 <Josh_Soref> ... might make sense
15:59:46 <Josh_Soref> burn: adambe, i hear you
15:59:50 <Josh_Soref> ... a problem i see is that
15:59:54 <Josh_Soref> ... if i request video
16:00:00 <Josh_Soref> ... and i'm given a Video device
16:00:03 <Josh_Soref> ... some device / some file
16:00:15 <Josh_Soref> ... my App is given a video Track from some device
16:00:25 <Josh_Soref> ... i don't know that i can control it
16:00:34 <Josh_Soref> ... i may discover as an application developer
16:00:42 <Josh_Soref> ... that it's useless to me
16:01:01 <Josh_Soref> adambe: in some scenarios where you give hard constraints
16:01:07 <Josh_Soref> ... you may not have a gUM dialog
16:01:12 <Josh_Soref> ... you may get a failure right away
16:01:17 <Josh_Soref> ack Josh_Soref 
16:01:17 <Zakim> Josh_Soref, you wanted to ask if an item will go away when the user closes the device source
16:01:51 <Josh_Soref> Josh_Soref: q+ to note that there are spying/profiling concerns in immediate fail w/o user interaction
16:02:03 <Josh_Soref> s/Josh_Soref: q+ to note that there are spying/profiling concerns in immediate fail w/o user interaction//
16:02:07 <Josh_Soref> q+ to note that there are spying/profiling concerns in immediate fail w/o user interaction
16:02:28 <Josh_Soref> adambe: with a modification api, you need the gUM and select dialog
16:02:35 <gmandyam> +q
16:02:42 <Josh_Soref> Jim_Barnett: on some devices there may be lots of sources
16:02:52 <Josh_Soref> fluffy: iPhone 2 cameras (front, back)
16:02:56 <Josh_Soref> ... you want hires
16:03:05 <Josh_Soref> ... if you can't do that in selection
16:03:13 <Josh_Soref> ... you'll probably get the wrong one
16:03:18 <Josh_Soref> ... and then when you change things
16:03:27 <Josh_Soref> ... it probably fails because you already have one
16:03:37 <Josh_Soref> ... i think you need control and constraints
16:03:45 <Josh_Soref> ... you need constraints even if you add control
16:03:53 <Josh_Soref> burn: when we came up w/ the initial proposal
16:03:56 <Zakim> -fluffy
16:04:04 <Zakim> -richt_
16:04:07 <Josh_Soref> ... it was because there were significant concerns about fingerprinting
16:04:25 <Josh_Soref> ... constraints 
16:04:34 <Josh_Soref> ... solves that
16:04:51 <Josh_Soref> CCC: i see a risk with a constraint based, not best effort
16:04:57 <Josh_Soref> ... you can probe the user's device
16:05:02 <Josh_Soref> ... by providing hard constraints
16:05:08 <stefanh> s/CCC/adambe/
16:05:09 <Josh_Soref> ... getting immediate error 
16:05:12 <Josh_Soref> ack Josh_Soref 
16:05:12 <Zakim> Josh_Soref, you wanted to note that there are spying/profiling concerns in immediate fail w/o user interaction
16:05:19 <Josh_Soref> ... the dialog never appears
16:05:21 <fluffy> q-
16:05:42 <Josh_Soref> ... i think that's the motivation TravisLeithead had
16:05:55 <Josh_Soref> TravisLeithead: the main fingerprinting concern is "drive-by" fingerprinting
16:05:55 <Zakim> +richt_
16:06:04 <Josh_Soref> ... we did some prototyping
16:06:15 <Josh_Soref> ... we considered firing early v. later
16:06:32 <Josh_Soref> ... because if it fired early, you'd be able to figure out if there's a camera at all
16:06:42 <Josh_Soref> ... with pure constraints, you can probe
16:06:48 <Josh_Soref> ... with best effort, you can't probe as much
16:07:01 <Josh_Soref> adambe: get-capabilities after you've been granted access to a track
16:07:13 <Josh_Soref> ... offer/peerconnection
16:07:18 <Josh_Soref> ... there's a lot of information in that offer
16:07:26 <Josh_Soref> ... you're already leaking that
16:07:39 <Josh_Soref> ... we had a ML discussion, hta , I and DDD
16:07:48 <Josh_Soref> ... TravisLeithead: how does gUM look with this?
16:07:56 <Josh_Soref> TravisLeithead: perhaps i didn't make that very clear
16:07:58 <Josh_Soref> ... the workflow is that
16:08:10 <Josh_Soref> ... each time the application calls gUM they get a new instance of a local MediaStream
16:08:30 <Josh_Soref> ... that local MediaStream will have at most one Video track and at most one Audio track
16:08:37 <Josh_Soref> ... if the application needs more devices, they call gUM again
16:08:54 <Josh_Soref> ... the success callback will have a second in this local streams list
16:09:00 <Josh_Soref> ... and you could combine them at that point
16:09:12 <Josh_Soref> ... the video/audio devices lists live on each stream
16:09:18 <Josh_Soref> ... they're essentially a singleton
16:09:32 <Josh_Soref> ... when you request the list, you're given a singleton
16:09:39 <Josh_Soref> ... one singleton for video, and one singleton for audio
16:10:01 <Josh_Soref> ... it doesn't matter which local media stream you query, the list is the same list
16:10:13 <Josh_Soref> ... if i turn off the camera, that source will be removed from that list
16:10:39 <Josh_Soref> adambe: how do you specify audio only / video only?
16:10:44 <Josh_Soref> ... is it gUM?
16:10:54 <Josh_Soref> TravisLeithead: i had no intention of removing options from gUM
16:11:04 <Josh_Soref> ... i think at a minimum audio:true/video:true is important
16:11:05 <burn> I find it interesting that the people most focused on the *use* of gUM want constraints, while the people most focused on the *implementation* of gUM do not.  Which is more appropriate for our target audience?
16:11:09 <Josh_Soref> adambe: that was my interpretation
16:11:21 <Josh_Soref> TravisLeithead: i'm opposed to mandatory constraints
16:11:27 <Josh_Soref> ... those seem to be where problems lie
16:11:30 <richt_> q+
16:11:37 <Josh_Soref> ... if you want a bunch of constraint hints for the UA/user
16:11:44 <Josh_Soref> ... to help select the most appropriate camera
16:11:55 <Josh_Soref> ... perhaps constraints can be constrained to just have optional
16:12:07 <Josh_Soref> ... perhaps it doesn't make sense to have constraints + control api
16:12:17 <dom> (removing mandatory constraints — interesting idea)
16:12:20 <Josh_Soref> hta: people definitely want to be able to change resolution
16:12:26 <Josh_Soref> +1 to removing mandatory
16:12:33 <Josh_Soref> ack burn 
16:12:38 <Josh_Soref> ack Dan
16:12:53 <Josh_Soref> burn: as someone who wants to build an app in HTML5 that behaves like a native app
16:12:57 <Josh_Soref> ... we have a trusted environment
16:13:02 <Josh_Soref> ... i don't want to show options
16:13:16 <Josh_Soref> ... i don't want to do any of that until i know i have something reasonable
16:13:40 <Josh_Soref> ... it seems like consumers want constraints
16:13:47 <Josh_Soref> ... but implementers do not [want hard constraints]
16:13:48 <dom> (I'll note that this distinction between "trusted environment" and "in-browser" is pretty fundamental in terms of API design; the Device APIs Working Group has suffered a very long time for trying to keep these two into a single API)
16:13:50 <Josh_Soref> ... i find that really interesting
16:14:03 <Josh_Soref> ... if we brought 20 app implementers
16:14:07 <Josh_Soref> ... they'd all want constraints
16:14:09 <Josh_Soref> adambe: i don't think so
16:14:18 <Josh_Soref> ... if you don't know anything about the machine
16:14:24 <Josh_Soref> ... how would you create the constraint object
16:14:34 <Josh_Soref> ... it's much easier to get something, decide if it will work for you
16:14:42 <Josh_Soref> ... and then negotiate with the user
16:15:04 <Josh_Soref> ... we'll have very complex constraints object if you don't know anything about the machine you're dealing with
16:15:11 <Josh_Soref> ... you could dig down into details
16:15:24 <Josh_Soref> hta: let's pay attn to the Queue
16:15:26 <Josh_Soref> ack gmandyam 
16:15:35 <Josh_Soref> gmandyam: TravisLeithead, you may have answered this too
16:15:40 <Josh_Soref> ... one thing that concerned me
16:15:47 <Josh_Soref> ... the still image capture UC
16:15:51 <Josh_Soref> ... to set up the preview
16:15:57 <Josh_Soref> ... which would be different from a video conf app
16:16:06 <Josh_Soref> ... i know there may be problems w/ mandatory constraints
16:16:16 <Josh_Soref> ... what concerns me is modulating the constraints after the track is created
16:16:22 <Josh_Soref> ... upon creation of the track
16:16:29 <Josh_Soref> ... being able to apply constraints immediately
16:16:39 <Josh_Soref> ... could provide a better UE over a wider range of browsers
16:16:42 <Josh_Soref> TravisLeithead: you're suggesting
16:16:47 <Josh_Soref> ... we have constraints before gUM
16:17:03 <Josh_Soref> ... we have a proposal to apply constraints to an existing track
16:17:17 <Josh_Soref> ... but you're proposing after gUM but before the track
16:17:25 <Josh_Soref> gmandyam: i'm advocating for constraints on gUM
16:17:36 <Josh_Soref> ... i'm worried about video:true/audio:true as the only available constraints
16:17:48 <Josh_Soref> ... which wouldn't be desirable for certain applications
16:17:57 <Josh_Soref> ... i know hta talked about changing constraints later
16:18:04 <Josh_Soref> ... i'm worried about variability
16:18:11 <Josh_Soref> ... i want to make a 10fps hi-res preview mode
16:18:17 <Josh_Soref> ... i invoke that
16:18:21 <Josh_Soref> ... but i don't get that
16:18:25 <Josh_Soref> ... err i get that
16:18:33 <Josh_Soref> ... if i'm restricted to video:true/audio:true
16:18:39 <Josh_Soref> ... i can't modify the track until it's created
16:18:43 <Josh_Soref> hta: i think we need to cut off soon
16:18:46 <Josh_Soref> ack richt_ 
16:19:08 <Josh_Soref> richt_: i want to talk about Why
16:19:11 <Josh_Soref> ... developers want constraints
16:19:19 <Josh_Soref> ... implementers don't want [hard] constraints
16:19:25 <Josh_Soref> ... what we're arguing over here
16:19:29 <Josh_Soref> ... it's vitriolic
16:19:32 <Josh_Soref> ... it's UE
16:19:37 <Josh_Soref> ... if you apply constraints up front
16:19:42 <Josh_Soref> ... it's before the prompt
16:19:54 <Josh_Soref> ... but what you do if you do it after the prompt
16:20:05 <Josh_Soref> ... the responsibility for rejecting users is left to the web app developer
16:20:11 <Josh_Soref> ... if you're up front rejecting someone
16:20:17 <Josh_Soref> ... that's an exclusive design philosophy
16:20:26 <Josh_Soref> ... that's not the web philosophy
16:20:34 <Josh_Soref> ... burn you mentioned trusted environments
16:20:40 <Josh_Soref> ... in those, you'll have no prompts
16:20:47 <Josh_Soref> ... there's no difference between early/later
16:20:59 <Josh_Soref> ... on the web, the responsibility lies with UAs
16:21:11 <Josh_Soref> ... it's about developers not wanting to take responsibility for not supporting their users
16:21:12 <Josh_Soref> Josh_Soref: +1
16:21:22 <Josh_Soref> hta: i think we'll conclude with that
16:21:28 <Josh_Soref> ... there's no consensus about changing gUM
16:21:46 <Josh_Soref> ... there seems to be consensus that changing tracks after creation is necessary
16:21:57 <Josh_Soref> Topic: Recording API
16:22:21 <Josh_Soref> TravisLeithead: i'd like to suggest we postpone this topic to a future Conference
16:22:45 <Josh_Soref> gmandyam: is still image capture considered in the api?
16:22:55 <Josh_Soref> TravisLeithead: i think richt_ 's proposal included it as a feature set of a video track
16:22:57 <Josh_Soref> ... i like that idea
16:23:03 <Josh_Soref> ... this is a swing thing
16:23:05 <Josh_Soref> ... it can go either way
16:23:16 <Josh_Soref> ... recording is about taking a stream and serializing to disk
16:23:29 <Josh_Soref> ... taking a picture is instantaneous operation
16:23:36 <Josh_Soref> ... it could be an operation 
16:23:42 <Josh_Soref> Jim_Barnett: it could be a separate module
16:23:45 <Josh_Soref> ... we could split it out
16:24:00 <burn> I disagree with you, richt, about there being no difference.  I also disagree about not supporting users.  Apps running on the iPhone are *very* different from ones running on the desktop.  There is a great increase in the variety of devices, rather than a decrease, and apps will need to be customized for those devices, even if written in HTML.  Developers *want* their apps to serve their users.  Any other assumption in a largely free market makes no sense.
16:24:01 <Josh_Soref> gmandyam: still image capture it could be locally stored, or in memory
16:24:07 <Josh_Soref> richt_: the reason it's on video stream
16:24:13 <Josh_Soref> ... you can take a picture on anything
16:24:16 <Josh_Soref> ... a camera, or not a camera
16:24:23 <Josh_Soref> ... if it's a camera, you could use flash too
16:24:30 <Josh_Soref> ... but it's a function of having a video
16:24:43 <Josh_Soref> gmandyam: there are two proposals for still image capture
16:24:49 <Josh_Soref> ... i'd propose that richt_ and i work on it
16:24:57 <Josh_Soref> ... but i don't want it to be deferred
16:25:03 <Josh_Soref> hta: it seems fairly separable
16:25:09 <Josh_Soref> ... so we should treat it as a separate module
16:25:20 <Josh_Soref> ... get it speced, agreed to, get implementations, sure
16:25:30 <Josh_Soref> gmandyam: i'll talk to rich offline
16:25:31 <Josh_Soref> Topic: Rich’ proposal for advanced video track control
16:25:40 <Josh_Soref> richt_: video stream, audio stream track
16:25:48 <Josh_Soref> ... tracks can be locked or not
16:25:56 <Josh_Soref> ... locked on a non local thing
16:26:03 <Josh_Soref> ... you're setting capabilities in lots of ways
16:26:12 <Josh_Soref> ... the proposal didn't go into detail, but you could see how it would work
16:26:22 <Josh_Soref> ... this is based on our user's requests
16:26:28 <Josh_Soref> ... focused on flash
16:26:43 <Josh_Soref> ... i think this is the simplest way to do it
16:27:05 <Josh_Soref> hta: another approach is to go from media stream track to the underlying device
16:27:12 <Josh_Soref> richt_: that'd be a smaller surface area
16:27:16 <Josh_Soref> ... which would be nice
16:27:29 <Josh_Soref> hta: every time i see a class that has a four-piece name
16:27:36 <Josh_Soref> ... which kind of seems like a hierarchy
16:27:44 <Josh_Soref> ... it feels like there's something wrong there
16:27:48 <Josh_Soref> richt_: i had the same hunch
16:28:05 <Josh_Soref> ... if we could query that object, and then transform it into a camera
16:28:10 <Josh_Soref> ... that'd be much nicer
16:28:17 <Josh_Soref> ... i think i've spent too much time in C++
16:28:24 <Josh_Soref> Josh_Soref: that works in Mozilla w/ QueryInterface :)
16:28:34 <Josh_Soref> richt_: the principle is sound, i think
16:28:45 <Josh_Soref> ... the reason it's simple
16:28:52 <Josh_Soref> ... is so we don't have to separate objects
16:29:09 <Josh_Soref> ... TravisLeithead 's thing introduces a risk of syncing objects
16:29:25 <Josh_Soref> hta: i think i prefer simple device objects and simple track objects to complex track objects
16:29:42 <Josh_Soref> ... but the jury is still out
16:29:57 <Josh_Soref> gmandyam: hta, you want the Still module to be separable
16:30:09 <Josh_Soref> hta: i think so
16:30:17 <Josh_Soref> ... i can't tell for sure w/o a proposal
16:30:23 <Josh_Soref> [ time check - time expired ]
16:30:33 <Josh_Soref> richt_: returning tracks from gUM
16:30:43 <Josh_Soref> ... i guess there's a dependency either way
16:31:03 <Josh_Soref> Topic: Close
16:31:14 <Josh_Soref> stefanh: i'd like to summarize actions
16:31:24 <Josh_Soref> ... Jim_Barnett to look at scenarios/requirements
16:31:39 <Josh_Soref> ... and TravisLeithead was going to revise a recording proposal
16:31:54 <dom> ACTION: Jim to look at scenarios/requirements
16:31:54 <trackbot> Sorry, couldn't find user - Jim
16:32:03 <dom> ACTION: Travis to work with Jim on updated recording proposal
16:32:04 <trackbot> Created ACTION-7 - Work with Jim on updated recording proposal [on Travis Leithead - due 2012-08-30].
16:32:23 <Josh_Soref> TravisLeithead: i think people making proposals should get together
16:32:27 <Josh_Soref> ... it's good to have common ground
16:32:36 <dom> ACTION: James to look at scenarios/requirements
16:32:36 <trackbot> Created ACTION-8 - Look at scenarios/requirements [on James Barnett - due 2012-08-30].
16:32:40 <Zakim> -adambe
16:32:42 <Josh_Soref> [ Adjourned ]
16:32:42 <Zakim> -hta
16:32:43 <Zakim> -richt_
16:32:45 <Zakim> -gmandyam
16:32:45 <Zakim> -Dan_Burnett
16:32:46 <Zakim> -Jim_Barnett
16:32:47 <Zakim> -stefanh
16:32:47 <Zakim> -Milan_Young
16:32:51 <Zakim> -Dom
16:32:52 <Zakim> -[Mozilla]
16:32:58 <Zakim> -Travis
16:33:05 <Zakim> -Josh_Soref
16:35:33 <adambe> adambe has left #mediacap
16:36:09 <Zakim> -yahui
16:36:33 <Zakim> -gaowenmei
16:36:34 <Zakim> UW_Web RTC(MediaCap)11:00AM has ended
16:36:34 <Zakim> Attendees were Dan_Druta, Josh_Soref, +1.408.902.aaaa, fluffy, +1.650.241.aabb, +1.407.835.aacc, hta, Dan_Burnett, +46.1.07.14.aadd, stefanh, +46.1.07.14.aaee, adambe, Dom, derf,
16:36:34 <Zakim> ... Jim_Barnett, gmandyam, gaowenmei, yahui, Travis, richt_, Milan_Young
16:40:27 <richt> richt has joined #mediacap
16:46:39 <Josh_Soref> trackbot, end meeting
16:46:39 <trackbot> Zakim, list attendees
16:46:39 <Zakim> sorry, trackbot, I don't know what conference this is
16:46:47 <trackbot> RRSAgent, please draft minutes
16:46:47 <RRSAgent> I have made the request to generate http://www.w3.org/2012/08/23-mediacap-minutes.html trackbot
16:46:48 <trackbot> RRSAgent, bye
16:46:48 <RRSAgent> I see 3 open action items saved in http://www.w3.org/2012/08/23-mediacap-actions.rdf :
16:46:48 <RRSAgent> ACTION: Jim to look at scenarios/requirements [1]
16:46:48 <RRSAgent>   recorded in http://www.w3.org/2012/08/23-mediacap-irc#T16-31-54
16:46:48 <RRSAgent> ACTION: Travis to work with Jim on updated recording proposal [2]
16:46:48 <RRSAgent>   recorded in http://www.w3.org/2012/08/23-mediacap-irc#T16-32-03
16:46:48 <RRSAgent> ACTION: James to look at scenarios/requirements [3]
16:46:48 <RRSAgent>   recorded in http://www.w3.org/2012/08/23-mediacap-irc#T16-32-36