01:14:14 <lgombos__> lgombos__ has joined #mediacap
01:40:11 <lgombos__> lgombos__ has joined #mediacap
03:56:49 <hta> hta has joined #mediacap
13:43:35 <RRSAgent> RRSAgent has joined #mediacap
13:43:35 <RRSAgent> logging to http://www.w3.org/2013/02/06-mediacap-irc
13:43:37 <trackbot> RRSAgent, make logs public
13:43:37 <Zakim> Zakim has joined #mediacap
13:43:39 <trackbot> Zakim, this will be MCAP
13:43:39 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
13:43:40 <trackbot> Meeting: Media Capture Task Force Teleconference
13:43:40 <trackbot> Date: 06 February 2013
13:43:42 <dom> ScribeNick: gmandyam
13:43:56 <dom> Chair: hta, stefanh
13:43:58 <fjh> fjh has joined #mediacap
13:44:08 <dom> s/Teleconference/F2F Meeting/
13:44:08 <gmandyam> HTA - going over conclusions from Feb. 5
13:44:21 <burn> burn has joined #mediacap
13:44:37 <gmandyam> HTA - Device enumeration has been concluded to be necessary, but there are privacy issues.
13:44:40 <stefanh> stefanh has joined #mediacap
13:45:28 <gmandyam> Martin - privacy issues were not in scope of current proposal, but for suggested expanded capabilities.  Additional device info could potentially improve privacy.
13:45:34 <gmandyam> HTA- Error handling will not change from current model.
13:46:05 <dan_romascanu> dan_romascanu has joined #mediacap
13:46:19 <gmandyam> Cullen - we should be consisten as to how we do error handling
13:46:50 <gmandyam> HTA - "Immediate Stream" ,i.e. synchronous gUM.  This belongs in a sense to PeerConnection.
13:47:08 <wonsuk> wonsuk has joined #mediacap
13:47:12 <jeromemarcon> jeromemarcon has joined #mediacap
13:48:48 <Dan_Druta> Dan_Druta has joined #mediacap
13:48:49 <dom> s/ - /: /
13:49:54 <dom> -> http://www.w3.org/wiki/images/9/90/Gum-identity-interim-2013-01.pdf Media Streams and Identity slides
13:50:30 <timeless> s/HTA -/hta:/g
13:50:32 <timeless> s/HTA-/hta:/g
13:50:41 <timeless> RRSAgent, draft minutes
13:50:41 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/06-mediacap-minutes.html timeless
13:50:54 <timeless> RRSAgent, make logs pyublic
13:50:56 <timeless> RRSAgent, make logs public
13:51:00 <timeless> RRSAgent, draft minutes
13:51:00 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/06-mediacap-minutes.html timeless
13:51:13 <timeless> s/HTA/hta/
13:51:15 <timeless> RRSAgent, draft minutes
13:51:15 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/06-mediacap-minutes.html timeless
13:51:22 <derf> s/Martin -/Martin:/g
13:51:29 <derf> s/Cullen -/Cullen:/g
13:51:36 <timeless> [ General Idea: Grant Media Access to an Idenity ]
13:51:39 <timeless> s/timeless/scribe/
13:51:45 <timeless> [ Topics ]
13:51:46 <timeless> s/timeless/scribe/
13:51:50 <timeless> RRSAgent, draft minutes
13:51:50 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/06-mediacap-minutes.html timeless
13:52:04 <timeless> [ Stream Isolation ]
13:52:05 <timeless> s/timeless/scribe/
13:53:23 <timeless> Scribe: Josh_Soref
13:53:25 <timeless> scribenick: timeless
13:53:28 <timeless> [ History ]
13:53:36 <timeless> ekr: we got three proposals
13:53:41 <timeless> ... I presented a 1st draft in Lyon
13:53:49 <timeless> ... i never got around to writing it up
13:53:55 <timeless> ... this is a detailed description of my proposal
13:54:04 <timeless> [ Three ways to call gUM (all constraints) ]
13:54:11 <timeless> ekr: * Call gUM()
13:54:13 <fluffy> fluffy has joined #mediacap
13:54:19 <timeless> ... Call gUM(noaccess=true)
13:54:24 <timeless> s/Call/* Call/
13:54:38 <timeless> ... I won't touch the stream
13:54:50 <timeless> ... * Call gUM(peerIdentity=bob@example.com)
13:54:55 <gmandyam> gmandyam has joined #mediacap
13:55:04 <timeless> ... This stream will only be sent to a certain identity
13:55:09 <timeless> [ Call gUM() as normal ]
13:55:15 <timeless> ekr: current behavior unchanged
13:55:15 <gmandyam> Hey Josh, are you scribing?  I'll quit if you are. - Giri
13:55:18 <timeless> [ noaccess=true ]
13:55:19 <fischman> fischman has joined #mediacap
13:55:30 <timeless> ekr: Media permissions checks as usual
13:55:38 <timeless> .. if site gets access, it gets permissions
13:55:39 <gmandyam> OK - let me know when you need a break
13:55:47 <timeless> ... stream is isolated
13:55:52 <timeless> ... keying must be via DTLS
13:56:03 <timeless> ekr: you [martin__] will say no to identity assertion
13:56:12 <timeless> martin__: this will enable creation of identity assertion based on stream
13:56:19 <timeless> ekr: once peer connection is established,
13:56:28 <timeless> ... it either knows peer identity
13:56:36 <timeless> ... browser displays identity and "no access" indicator
13:56:51 <timeless> ekr: WebEx etc want to guarantee to others
13:56:56 <timeless> ... and customers want to check
13:57:01 <timeless> ... that the site didn't screw them over
13:57:06 <timeless> [ Flow slide ]
13:57:19 <timeless> ekr: indicator has an identity assertion
13:57:26 <timeless> [ peerIdentity=bob@example.com ]
13:57:33 <timeless> ekr: originally suggested by cullen?
13:57:39 <timeless> ... more enhanced from user perspective
13:57:56 <timeless> ... people seem to be concerned about allowing a site to have access for perpetuity
13:58:07 <timeless> ... "i only want to allow site to call X and Y and no one else"
13:58:16 <timeless> ... site indicates to user who the content will be sent to
13:58:24 <timeless> ... either RFC822 style email address
13:58:37 <timeless> ... or Browser if it has Contacts accesss, it could show name + icon
13:58:47 <timeless> Ted: for Poker site example
13:58:58 <timeless> ... would it be skiptracer@pokersite.example ?
13:59:03 <timeless> ... but could you do player1@ ?
13:59:10 <timeless> ... or would you need a different mechanism
13:59:17 <timeless> ekr: i think you'd outsource identity assertion
13:59:38 <adambe> adambe has joined #mediacap
13:59:40 <timeless> martin__: to do a Player 1
13:59:47 <timeless> ... you need player1@pokerstars.example
13:59:51 <timeless> ... the name is in this form
14:00:00 <timeless> ... and the domain for this domain can do the identity assertion
14:00:12 <timeless> ekr: you need to be able to mechanically identify this person
14:00:19 <timeless> s/Ted:/TedHardie:/
14:00:35 <timeless> TedHardie: this isn't valid for the poker table case without pokerstars preminting
14:00:41 <timeless> martin__: just minting
14:00:57 <timeless> Dan_Druta: there's a concern about information harvesting
14:01:05 <timeless> gmandyam: what if you want to do a native media player
14:01:25 <timeless> ... if i want to use the recording api
14:01:34 <timeless> martin__: you'd use the gUM(noaccess=false)
14:01:38 <timeless> ... you don't need to set the argument
14:01:46 <timeless> gmandyam: what would this mean for access?
14:01:52 <timeless> ekr: access will be on `origin` basis
14:02:09 <timeless> gmandyam: for access to raw media?
14:02:13 <timeless> ekr: you'll still have that
14:02:21 <timeless> ... this is a new way to restrict access
14:02:30 <timeless> gmandyam: what motivates a web site to do this?
14:02:44 <timeless> cullen: sites like WebEx want to be able to assure customers that they *don't* have access to the media
14:02:51 <timeless> ... they'll choose to use this mechanism
14:03:06 <timeless> ... and users could verify this by something morally equivalent to the lock icon today
14:03:17 <timeless> justin: what does it mean for WebEx to not have access to the media?
14:03:22 <timeless> ... surely they'll have the data
14:03:33 <timeless> cullen: WebEx won't have the keying material
14:03:40 <timeless> ... for a Point to Point Call
14:03:48 <timeless> ... it knows martin__ called ekr
14:03:54 <timeless> ... and for a TURN server, it might all flow through
14:04:01 <timeless> ... but it doesn't have the keying material
14:04:06 <timeless> ... for a 10 person conference
14:04:16 <timeless> ... you might know who is sending the content v. spreading
14:04:21 <timeless> ... but you won't know what was sent
14:04:27 <timeless> ... for WebEx or Google Hangouts
14:04:34 <timeless> ... if Microsoft and Silverlake
14:04:43 <timeless> ... are doing some deal about how Cisco would go out of business
14:04:48 <timeless> ... they want assurance that we aren't listening
14:04:54 <timeless> justin: but in a WebEx conference
14:05:02 <timeless> ... the central node won't have any access to the media?
14:05:14 <timeless> ... what assertion covers the end to end
14:05:22 <timeless> ... that it won't have access to the media?
14:05:32 <timeless> cullen: for 1-1 i'm saying we can do it
14:05:46 <timeless> aroach: if identity asserter and site you're on
14:05:54 <timeless> ... are the same or are in collusion, you're ...
14:05:56 <timeless> ekr: you're hosed
14:06:06 <timeless> ... this is about a site being able to provide you with evidence
14:06:14 <timeless> ... but you have to trust the source of the communicating counterpart
14:06:23 <timeless> XX: we're pushing trust from site hosting JS
14:06:28 <timeless> ... to site hosting identification
14:06:39 <timeless> ekr: or a site with extra ...
14:06:43 <timeless> XX: are we confusing the user
14:06:50 <timeless> ... about do you trust X v. Y.com ?
14:06:54 <timeless> ekr: always some risk
14:07:04 <timeless> ... people have some sense that domains control identities
14:07:15 <timeless> ... some sense,
14:07:22 <timeless> ... companies reassign email addresses
14:07:29 <timeless> ... Gmail can redirect email somewhere else
14:07:42 <timeless> ... 2. there's a lot of work in distributed identification systems
14:07:44 <timeless> ... BrowserID
14:07:50 <timeless> ... it's a lot more straightforward to do a calling site
14:07:54 <timeless> ... than an identity provider
14:08:01 <timeless> ... so your identity is likely to be by someone you trust
14:08:12 <timeless> ... but the caller site something less trusted
14:08:18 <timeless> ... 3. this is what we know how to do
14:08:30 <timeless> s/XX:/PeterThatcher:/
14:08:31 <timeless> s/XX:/PeterThatcher:/
14:09:00 <timeless> ekr: MediaStream can only be connected to a PeerConnection with identity provided
14:09:00 <mauro> mauro has joined #mediacap
14:09:16 <timeless> ... completion would choke if call goes elsewhere
14:09:33 <timeless> [ ekr explains call flow ]
14:09:49 <timeless> ekr: that's the entirety of the mechanism
14:09:55 <timeless> ... i can send to the list on the details
14:10:00 <timeless> ... but it's simple
14:10:09 <timeless> gmandyam: can you go back to the call flow slide?
14:10:14 <timeless> ... this is entirely voluntary
14:10:22 <timeless> ... the web site can contact the ID provider directly
14:10:29 <timeless> ... the web site can put up its own dialog box
14:10:41 <timeless> ... it can ask user "can i send to bob@example.com"
14:10:44 <timeless> ... why add to gUM
14:10:52 <timeless> ekr: this is for Identity where you don't trust calling site
14:11:01 <timeless> ... this is about denying calling site access to media
14:11:17 <timeless> gmandyam: the web site can get access to the media by not doing this
14:11:58 <timeless> ekr: this is a way to build a site where the user can verify the site isn't sniffing
14:11:58 <timeless> cullen: there's a reason the browser needs to show the Lock icon
14:11:58 <timeless> ... instead of the web site showing "secured by Thawt"
14:12:02 <timeless> ekr: they do that to though ;-)
14:12:21 <timeless> cullen: this is about the chrome of the browser showing the assertion
14:12:33 <timeless> ami: how does bob tell his PeerConnection that he's bob@example.com
14:12:39 <timeless> ekr: that's defined in IETF drafts
14:12:52 <timeless> jesup: in addition to who puts up the assertion
14:12:56 <timeless> ... and whether they can access the media
14:13:03 <timeless> ... even if you trust the site to not access the media
14:13:08 <timeless> ... the site can always be hacked
14:13:14 <timeless> ... so trusting them
14:13:18 <timeless> ... if they're hacked
14:13:44 <timeless> ... worse case they won't get the media
14:13:54 <timeless> ekr: i'll send detailed text for the proposal
14:14:01 <timeless> [ Recording Consent ]
14:14:20 <timeless> ekr: W3C (will have?) published recording API as FPWD
14:14:29 <timeless> ... do we need special recording consent?
14:14:34 <dom> s/[ Recording Consent ]/Topic: Recording Consent
14:14:35 <timeless> [ Basic Recording Concept (review) ]
14:14:40 <timeless> ekr: i think i'm summarizing correctly
14:14:46 <timeless> ... MediaStream
14:14:53 <timeless> .. feed it to MediaRecording() constructor
14:14:58 <timeless> ... js gets direct access to media
14:15:06 <timeless> s/.. feed/... feed/
14:15:14 <timeless> [ Why the special permissions? ]
14:15:22 <timeless> ekr: quoting Ben Pedtick
14:15:34 <timeless> ... there are regulatory requirements for such notifications
14:15:42 <timeless> [ Not the only way to get direct access ]
14:15:49 <timeless> ekr: people suggested building it into the browser interface
14:15:59 <timeless> ... Pipe MediaStreeam to PeerConnection
14:16:02 <timeless> ... record on server
14:16:06 <timeless> ... loop back to client
14:16:11 <timeless> ... video can be read to Canvas
14:16:27 <timeless> ... no technical measure can distinguish recording from a webrtc call to an arbitrary location
14:16:54 <timeless> ... no matter how many dialogs we pop up
14:17:03 <timeless> ... there's a way to build something that avoids the dialogs
14:17:09 <timeless> [ Proposed Resolution ]
14:17:24 <timeless> ekr: what you want to do is often to have the recording on the remote side
14:17:36 <timeless> ... I'd propose not having extra permissions
14:17:46 <timeless> ... and say it's the application's job to deal w/ regulatory requirements
14:17:57 <timeless> ... Chrome and Firefox already render indicators that the media is in use
14:18:19 <timeless> ... we could add a UI for a tape drive
14:18:24 <timeless> ... but i think that should be done in content
14:18:29 <timeless> Josh_Soref: +1
14:18:34 <timeless> martin__: +1
14:18:47 <timeless> martin__: concern that we document this decision in Security and Privacy
14:19:04 <JonLennox> JonLennox has joined #mediacap
14:19:11 <timeless> PeterThatcher: when you're telling the user that media will be sent
14:19:22 <timeless> ... would it be good for the browser to have fine detail that the media could be recorded
14:19:24 <dom> ACTION: ekr to draft text on no-permission-required for recording for inclusion in the mediastream-recording doc
14:19:24 <trackbot> Error finding 'ekr'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/mediacap/track/users>.
14:19:29 <dom> ACTION: eric to draft text on no-permission-required for recording for inclusion in the mediastream-recording doc
14:19:29 <trackbot> Created ACTION-16 - Draft text on no-permission-required for recording for inclusion in the mediastream-recording doc [on Eric Rescorla - due 2013-02-13].
14:19:35 <timeless> ... as part of the Chrome
14:20:08 <gmandyam> Clarification: Permission check only on gUM, not for recording is current proposal.  This is independent of ekr's proposal about a peerIdentity argument for gUM.
14:20:14 <timeless> ekr: "maybe this is being recorded and sent to your mom"
14:20:19 <timeless> PeterThatcher: if there isn't identity stuff
14:20:26 <timeless> ... "maybe it could go anywhere"
14:20:41 <timeless> cullen: when you turn on your computer, you may be recorde
14:20:46 <timeless> s/recorde/recorded/
14:21:12 <timeless> ... and when the green light goes on, you *are* being recorded
14:21:21 <timeless> ... i'm fine with "documenting that recording happens"
14:21:55 <timeless> Topic: Settings and Constraints
14:21:57 <martin__> and the only reason that I made the suggestion is so that we don't have to have these sorts of discussions ever again
14:22:49 <timeless> [ Dynamic usable constraints ]
14:23:25 <timeless> burn: for people who want to use media locally
14:23:34 <timeless> ... the constraint mechanism didn't do well for what you had to do in the browser
14:23:45 <timeless> ... Travis spent a lot of time thinking about how this would work
14:23:54 <timeless> ... the original constraint proposal was for selecting a stream
14:24:01 <timeless> ... but there was no ability to change constraints over time
14:24:03 <ekr> ekr has joined #mediacap
14:24:05 <dom> -> http://www.w3.org/wiki/images/f/fd/Constraints20130406.pdf Constraints and settings
14:24:07 <timeless> ... what if you want to change the settings of the camera
14:24:15 <timeless> ... Travis came up with the proposal
14:24:24 <timeless> ... he did most of the work, and gets credit for what's good
14:24:30 <timeless> ... i get credit for what's confusing
14:24:35 <timeless> [ Constraints mini-review ]
14:24:40 <timeless> burn: a brief overview
14:24:42 <Ted_Hardie> Ted_Hardie has joined #mediacap
14:24:49 <timeless> ... when requesting media, you can give a set of constraints
14:24:54 <timeless> ... mandatory and optional
14:24:59 <timeless> ... both sections are optional
14:25:07 <timeless> ... mandatory section says
14:25:11 <Ted_Hardie> Ted_Hardie has left #mediacap
14:25:21 <timeless> ... "if you can't give me a track that satisfies these constraints, then i want an error"
14:25:28 <timeless> ... the optional section is ordered
14:25:39 <timeless> ... these are constraints i'd like to be satisfied, but if you can't, that's ok
14:25:55 <timeless> ... maybe you ask for Width, and aspect ration
14:25:59 <timeless> s/ration/ratio/
14:26:06 <timeless> ... but maybe Width is more important
14:26:22 <timeless> ekr: we still have audio:true/video:true?
14:26:24 <timeless> burn: yes
14:26:33 <timeless> ... i'm not even showing this is for video or for audio
14:26:40 <timeless> ... you have separate constraints for audio and video
14:26:49 <timeless> ... there were differing versions of for audio or video
14:26:50 <ekr> ekr has joined #mediacap
14:27:07 <timeless> cullen: can i have a width-min in one row
14:27:16 <timeless> ... and below that a width-max below
14:27:18 <timeless> burn: yes
14:27:25 <timeless> ... i pulled this from an example
14:27:34 <timeless> ... you can have constraints multiple times (e.g. width-min)
14:27:39 <timeless> ... earlier ones are higher priority
14:28:04 <timeless> [ Based on Travis's Settings v6 proposal ]
14:28:04 <timeless> burn: there was a little email traffic, not a lot
14:28:12 <Travis> Travis has joined #mediacap
14:28:12 <timeless> ... when Travis and I discussed it last week, a few things required tweaking
14:28:17 <Travis> Present+ Travis_Leithead
14:28:19 <timeless> ... some things are slightly different from that proposal
14:29:13 <timeless> [ The Problem ]
14:29:13 <timeless> burn: it's called the Settings proposal
14:29:13 <timeless> ... even though v6 removed "Settings" from the proposal
14:29:15 <timeless> ... setting width to a number
14:29:18 <timeless> ... say 650
14:30:09 <timeless> ... is by setting the value, or using min+max to the same value
14:30:09 <timeless> ... here is why we have this proposal
14:30:09 <timeless> ... when you go to get video from the camera
14:30:09 <timeless> ... you could display it in multiple <video> elements
14:30:09 <timeless> ... send it over PeerConnection
14:30:09 <timeless> ... multiple sinks
14:30:10 <timeless> ... multiple Tracks with the same underlying source
14:30:17 <timeless> ... you could have different requirements for the underlying source
14:30:30 <timeless> ... what you want to send over PeerConnection could be a different framerate than what you show
14:31:02 <timeless> ... when you send to a Sink, that could have different characteristics than
14:31:02 <timeless> ... your source
14:31:02 <timeless> ... and the browser has to come up with something to do
14:31:02 <timeless> ... capabilities of source may change dynamically
14:31:07 <timeless> ... something the browser does
14:31:15 <timeless> ... or the user does
14:31:20 <timeless> ... the camera could go away
14:31:25 <timeless> ... or be physically muting it
14:31:34 <timeless> ... you could sometimes want a thumbnail
14:31:39 <timeless> ... or sometimes want a full video
14:31:46 <timeless> ... Sink could change on the fly
14:32:02 <timeless> [ Home Client ]
14:32:10 <timeless> burn: Video Camera generating stream of 1920x1200
14:32:31 <timeless> ... two tracks with the same source
14:32:36 <timeless> ... neither constrained
14:32:43 <timeless> ... each track is attached to its own <video>
14:33:02 <timeless> ... one <video width=1920 height=1200>, one <video width=320 height=200>
14:33:10 <timeless> ... the browser will upscale/downscale
14:33:17 <timeless> ekr: in most examples today
14:33:28 <timeless> ... people don't generally create Tracks
14:33:35 <timeless> ... is the idea we do gUM() once?
14:33:43 <timeless> burn: how you get different video sources
14:33:45 <timeless> ... vs. the same
14:33:49 <timeless> ... there's some discussion
14:34:11 <timeless> ... the next slide may ... it may not matter that it's two tracks or one
14:34:29 <timeless> [ Next slide ]
14:34:38 <timeless> burn: say the 1920x1200 video is changed
14:34:50 <timeless> ... to <video width=1024 height=768>
14:35:00 <timeless> ... the browser will likely scale, as it was for the other sink
14:35:08 <timeless> ... this change doesn't require the source to change
14:35:22 <timeless> jim: ekr's proposal
14:35:29 <timeless> ... if you set the stream element as isolated
14:35:35 <wonsuk> wonsuk has joined #mediacap
14:35:35 <timeless> ... would the js be able to do anything with it?
14:35:43 <timeless> burn: you can have a source that's remote, or from file
14:35:55 <timeless> martin__: tracks that you get back can be manipulated in any number of ways
14:35:58 <timeless> ... by setting constraints
14:36:06 <timeless> ... you just can't manipulate the pixel/audio data
14:36:19 <timeless> burn: this proposal is independent of that permission discussion
14:36:31 <timeless> gmandyam: the examples here are downscaling
14:36:36 <timeless> ... if you do upscaling
14:36:43 <timeless> ... and there was a mandatory constraint
14:36:55 <timeless> ... can the UA do postprocessing to enhance the video
14:37:04 <timeless> burn: upscaling and constraints-mandatory
14:37:18 <timeless> gmandyam: you have a source
14:37:28 <timeless> ... and the browser wants to avoid making it grainy
14:37:37 <timeless> ... so it postprocesses which increases delay
14:38:00 <timeless> burn: in this example, there are no constraints set on the track
14:38:05 <timeless> ... that's important for this example
14:38:11 <timeless> ... i'm happy w/ whatever i get from the camera
14:38:14 <timeless> ... and whatever it needs to do
14:38:21 <timeless> ... if it needs to do upscale/processing
14:38:25 <timeless> ... i'm fine with that in this example
14:38:49 <timeless> burn: regardless of what the source provides
14:38:52 <timeless> ... and track constraints
14:39:01 <timeless> ... the browser will try to do the most intelligent thing it can
14:39:05 <timeless> ... if the track goes away
14:39:07 <timeless> ... that's an error
14:39:13 <timeless> ... otherwise, the browser will do something reasonable
14:39:19 <timeless> ... if the application doesn't like what it did
14:39:23 <timeless> ... then it can set constraints
14:39:29 <timeless> ... to control things available to the sink
14:39:52 <timeless> cullen: we had a long discussion a year or two ago
14:40:06 <timeless> ... <video> should be the only thing to do upscaling
14:40:13 <timeless> ... Track won't
14:40:15 <lgombos> lgombos has joined #mediacap
14:40:18 <timeless> ... Track could Downscale
14:40:24 <timeless> ... if you duplicate for something that will be smaller
14:40:28 <timeless> ... the Track could downscale
14:40:33 <timeless> ... and as a general rule of thumb
14:40:42 <timeless> ... things should choose largest possible within constraints
14:40:52 <timeless> burn: cullen is describing guidelines
14:40:59 <timeless> ... not to go into the spec as normative text
14:41:09 <timeless> cullen: understanding that this is what will happen
14:41:16 <timeless> ... makes it possible to understand that this proposal would work
14:41:24 <timeless> burn: understand that browsers want to do these things
14:41:28 <timeless> ... this is an interface
14:41:34 <timeless> ... for the application to talk to the browser
14:41:38 <timeless> ... but still allow operation
14:41:44 <timeless> [ Next slide ]
14:42:22 <timeless> burn: although the decrease in the largest <video> tag didn't mandate a change on the video source
14:42:28 <timeless> ... it may result in  a change by the browser
14:42:34 <timeless> ... if the browser wants to inform the source
14:42:42 <timeless> ... that it'd be better to get a 1024x768
14:42:50 <timeless> ... that has an effect on Tracks
14:42:54 <timeless> ... but not Constraints on Tracks
14:43:02 <timeless> martin__: there's an Aspect Ratio change
14:43:13 <timeless> ... in the original state
14:43:19 <timeless> ... the 320x200 probably had letterbox
14:43:41 <timeless> ... as a result of changing the display in the big <video>
14:43:48 <timeless> ... you potentially changed the source
14:43:59 <timeless> ... which removes the letterbox in the small <video>
14:44:08 <timeless> ... it isn't intuitive, but it makes a lot of sense
14:44:17 <timeless> burn: but if you don't like that behavior, you could create constraints for it
14:44:21 <timeless> [ The Proposal Summary ]
14:44:28 <timeless> burn: separate notions of "source", "track", "sink"
14:44:41 <timeless> ... Media Capture Streams document doesn't give direct control over source or sink
14:44:43 <timeless> ... only tracks
14:44:53 <timeless> ... source configuration can change at any time
14:45:00 <timeless> ... browser will adjust what's sent to Track
14:45:03 <timeless> ... or have an event
14:45:31 <timeless> [ The Proposal (Expanded) ]
14:45:35 <timeless> burn: what's a source?
14:45:47 <timeless> ... Camera, microphone, RTCPeerConnection, file, Screen Capture
14:45:54 <timeless> ... no direct acces or control by app
14:45:57 <timeless> ... browser configures
14:46:01 <timeless> ... what's a Track?
14:46:05 <timeless> ... it's a constraint carrier
14:46:11 <timeless> ... and it holds statistics
14:46:20 <timeless> ... logically, it represents an incarnation of the media
14:46:27 <timeless> ... you could create 2 tracks with different constraints
14:46:34 <timeless> ... if you attach them to a PeerConnection
14:46:42 <timeless> ... there could be different resolutions of media sent on the two
14:47:08 <timeless> ... What are sinks?
14:47:13 <timeless> ... <video>, PeerConnection
14:47:15 <timeless> ... Recording
14:47:29 <timeless> ... No direct access or control via Media Capture/WebRTC APIs
14:47:39 <timeless> s/... Recording//
14:47:47 <timeless> s/PeerConnection/PeerConnection, Recording/
14:47:59 <timeless> cullen: can Track connect to Track?
14:48:04 <timeless> burn: no
14:48:11 <timeless> ... i'd have to think about what it means
14:48:16 <timeless> martin__: not on slide
14:48:20 <timeless> ... is MediaProcessing API
14:48:41 <timeless> ... that takes Source Sink and produces a Track ?
14:48:50 <timeless> hta: in the original proposal
14:48:55 <timeless> ... we could connect Tracks to Tracks
14:49:01 <timeless> ... after scratching our heads for months
14:49:03 <timeless> ... we removed it
14:49:14 <timeless> Dan_Druta: we haven't discussed <source> being a <video> element
14:49:26 <timeless> ... i think recording should allow saving a streamed item
14:49:35 <timeless> burn: this isn't an exhaustive list
14:49:45 <timeless> Dan_Druta: i like the concept of source, track, sink
14:49:47 <timeless> jim: +1
14:50:07 <timeless> burn: room full of programmers, no explicit "..." then it isn't there
14:50:10 <timeless> [ laughter ]
14:50:16 <timeless> ekr: i have a camera w/ 4x3
14:50:25 <timeless> ... but i have a mandatory constraint for 16:9
14:50:26 <fjh> +1 to concept of source, track, sink
14:50:34 <timeless> ... is it acceptable to pillow box it?
14:50:40 <timeless> burn: Tracks have constraints
14:50:49 <timeless> ... if you request a 16:9 mandatory constraint
14:50:53 <timeless> ... you'll get a failure right away
14:51:00 <timeless> ... that media can't give you that
14:51:19 <timeless> martin__: if you want pillowbox
14:51:26 <timeless> ... you'd create it w/o that constraint
14:51:30 <timeless> burn: it's up to the browser
14:51:37 <timeless> ... if you say you want to receive a video that's 16:9
14:51:46 <timeless> ... a browser may try to be intelligent and do that mapping for you
14:51:55 <timeless> ekr: if we start moving constraints away
14:52:00 <timeless> ... from sources
14:52:06 <timeless> ... i start to wonder how much i'm being allowed
14:52:16 <timeless> ... do i lose the ability to
14:52:28 <timeless> burn: having a constraint for `native resolution` might make sense?
14:52:31 <timeless> custin: i have a 4:3 in
14:52:36 <timeless> ... and i want to munge to 16:9
14:52:41 <timeless> ... by cropping top+bottom
14:52:57 <timeless> ... i ask camera to give me 16:9, i'd want it to do that for me
14:53:12 <timeless> burn: we'll have to define that in the aspect-ratio constraint
14:53:19 <timeless> hta: we're descending into details
14:53:27 <timeless> ... i'd like to get to the rest of the slides
14:53:49 <timeless> justin: looking forward to future discussion
14:54:05 <timeless> burn: i believe it can accommodate
14:54:18 <timeless> burn: there's a lot in the browser that's impl depenedent
14:54:26 <fischman> fischman has joined #mediacap
14:54:29 <timeless> jesup: i think it's reasonable when you apply a constraint to a Track
14:54:49 <timeless> ... the constraint could be satisfied by the source
14:54:59 <timeless> ... how much could be impl dependent
14:55:10 <timeless> cullen: on constraints that imply change to the media
14:55:23 <timeless> ... the standard should be such that browsers are consistent
14:55:36 <timeless> ... if setting a constraint causes media to get twisted around a Torus
14:55:42 <martin__> the thought occurs that mandatory and optional aren't the only categories in this "constraints" taxonomy: the mandatory category might be split into "fail if you can't do this" and "make it this way, no matter what it takes"
14:55:44 <timeless> ... it has to happen the same way in all browsers
14:56:32 <timeless> ekr: it isn't that i care about aspect ratio
14:56:38 <JonLennox> martin__ - what's the difference?
14:56:42 <timeless> ... i'm concerned that if one way to satisfy is DSP processing
14:56:48 <timeless> ... then how constraints actually operate
14:56:51 <timeless> ... for device selection
14:57:03 <timeless> ... you could satisfy and constraint-A is more important than constraint-B
14:57:14 <timeless> ... but you choose to do DSP on device-1
14:57:25 <timeless> burn: personal opinion is browser shouldn't do munging from Source to Track
14:57:36 <timeless> ... Track has certain
14:57:42 <timeless> ... it's the Sink that does the mapping
14:57:50 <timeless> Paul: a little fuzzy
14:57:57 <timeless> ... the browser can control the source
14:58:07 <ekr> ekr has joined #mediacap
14:58:09 <timeless> ... to make it better suited to the constraints of the track
14:58:36 <timeless> ... what about pan/zoom?
14:58:43 <timeless> burn: we talked about pan/zoom yesterday
14:58:49 <timeless> ... and i realized it works differently
14:58:55 <timeless> martin__: pan/zoom might be different
14:59:02 <timeless> ... like the constraints
14:59:17 <timeless> ... must not request processing of source
14:59:34 <timeless> ... if we make it clear that "must not do processing"
14:59:38 <timeless> burn: i agree
14:59:49 <timeless> ... that's been the mental model i've had the whole time
14:59:56 <timeless> derf: +1 to martin__
15:00:05 <timeless> ... any constraint that requires DSP'ing the source
15:00:08 <timeless> ... we shouldn't do
15:00:17 <timeless> ... on some platforms it'll be good, and on some, it'll fail
15:00:23 <timeless> burn: hearing +1s
15:00:49 <timeless> ... anyone who does not want Sources to give Tracks directly what is asked for in constraints w/o DSPing?
15:00:58 <timeless> justin: can we avoid the double negative?
15:01:04 <timeless> ... is crapping DSP?
15:01:11 <timeless> cullen: what about Echo-Cancelation?
15:01:26 <timeless> burn: if source provides something a certain way
15:01:29 <JonLennox> s/crapping/cropping/
15:01:32 <timeless> ... how the source provides it is acceptable
15:01:38 <timeless> ... it's the browser doing it that's a problem
15:01:51 <timeless> justin: if camera does VGA and i want 16:9, there needs to be a way to get it
15:01:58 <timeless> martin__: key is browser not doing stuff
15:02:08 <timeless> ... if you want 16:9 from 4:3
15:02:10 <Travis> Let's not forget that there are track constraints and sink constraints (video tag)
15:02:14 <timeless> ... you can push it in a 16:9 <video>
15:02:36 <timeless> cullen: if i gUM() and i directly connect to <video> it shouldn't need me to pull out and reprocess
15:03:06 <timeless> hta: we're discussing unobservable control surfaces
15:03:18 <adam> adam has joined #mediacap
15:03:28 <timeless> ... there's no way to discover the difference between to track / from track
15:03:31 <timeless> ekr: it is
15:03:35 <timeless> burn: it is with PeerConnection
15:03:55 <timeless> ekr: what to do w/ 4:3 input and 16:9 display
15:04:10 <timeless> cullen: i want to send something specific and your camera is different
15:04:14 <timeless> ... i need it to just work
15:04:22 <timeless> ... and cropping or letterboxing needs to be fairly consistent
15:04:34 <timeless> hta: get through the presentation?
15:04:42 <timeless> ekr: example case of general principle
15:04:49 <timeless> jesup: interested to hear what ekr says
15:04:54 <timeless> ... consider native resolution of camera
15:05:00 <timeless> ... may be willing to give any res
15:05:06 <timeless> ... but many will DSP to give any res
15:05:19 <timeless> ekr: constraints is to prioritizing which device to select
15:05:31 <timeless> justin: sourceid select a specific device
15:05:37 <timeless> ekr: i have 2 cameras
15:05:41 <timeless> ... one suitable for aspect ratio i want
15:05:51 <timeless> ... one much less suitable
15:05:53 <timeless> ... first constraint is aspect ratio
15:06:00 <timeless> ... browser decides to rescale video
15:06:06 <timeless> ... choice alg is selected by ordered choice
15:06:52 <dom> timeless: I'm used to getUserMedia with a pop up allowing the user to select a device that matches the constraints set by the application
15:07:23 <wonsuk> wonsuk has joined #mediacap
15:07:31 <dom> burn: when multiple sources can satisfy all the mandatory constraints, it goes through the optional ones to further filter
15:07:43 <dom> ... if after that there are still more than one, it's up to the browser to select
15:07:51 <dom> ... where the user can be involved in the user
15:08:37 <lgombos> lgombos has joined #mediacap
15:09:23 <timeless> s/timeless:/Josh_Soref:/
15:09:59 <dom> scribenick: dom
15:10:21 <dom> burn: let's finish the slides to look at the peerconnection case
15:10:32 <Travis> There's a dichotomy of desired full-and-absolute control by the app, and variability wiggle-room by the UA. As long as UA can have wiggle-room, then there will be cases where two implementations will be different.
15:11:09 <dom> juberti: real world cases of multiple devices is front camera has lower resolution than back camera
15:11:17 <dom> ... but in many cases, front camera is what you will want
15:11:41 <dom> ... Are there many cases where resolution matters more than what the camera is looking at?
15:12:05 <dom> burn: there are many cases where your app has specific resolution requirements
15:12:18 <dom> ... if your app cares more about the orientation of the device, then that's what your constraints should impose
15:12:34 <dom> ... the app has to pick its constraints in accordance with its needs
15:13:07 <dom> burn: there may different behavior for selecting via constraints, and controlling via settings
15:13:34 <Travis> I'm concerned about splitting those scenarios (selection vs. settings changes)
15:13:37 <dom> ... settings is "make it so no matter what", whereas constraints is "only give it to me if it is so"
15:14:18 <dom> randell: I'm concerned we're doing a lot of procedures, algorithms, failure cases, for relatively small slice of applications that require very specific device characteristics
15:14:40 <dom> ... for apps that don't want to let the user pick what the best camera/mike would be
15:15:04 <dom> burn: I would argue that applications care a lot about that
15:15:28 <dom> ... e.g. to match what native apps can do
15:16:19 <timeless> scribenick: timeless
15:16:30 <timeless> dom: i'd prefer we don't say many apps that do this
15:16:37 <timeless> ... but specific examples
15:16:41 <timeless> ... computer vision is a small UC
15:16:59 <timeless> burn: how many people have developing Web Apps as their primary job for them or their companies
15:17:04 <timeless> ... I see 2 hands
15:17:11 <timeless> ... be very careful about optimizing for impl
15:17:15 <timeless> ... when we don't have primary users
15:17:27 <timeless> ... my company is more interested in enabling users to build specific apps
15:17:29 <timeless> ... i don't do that
15:17:33 <timeless> ... but the people i work w/ do
15:17:52 <timeless> adambe: constraints when you select a device v. setting on Track
15:18:01 <timeless> ... discussion about are constraints remembered
15:18:08 <timeless> ... can i read out constraints from the track?
15:18:17 <timeless> burn: i'll get to that
15:18:27 <timeless> adambe: when someone sends me a track over PeerConnection
15:18:37 <timeless> ... the PeerConnection is from my PoV is the source
15:18:41 <Travis> We need to finish the slides...
15:18:41 <timeless> ... it's configured some way
15:18:50 <timeless> ... can i read out those constraints from my Track?
15:18:56 <timeless> burn: let me finish the slides
15:19:03 <ekr> ekr has joined #mediacap
15:19:06 <timeless> [ Home Client; Away Client ]
15:19:19 <timeless> Local source 800x600 video camera
15:19:41 <timeless> Three local sinks: <video w:1920 h:1200> <video w:320 h:200>
15:20:15 <timeless> Remote sinks: <video w:150 h:100> <video w:1024 h:768>
15:20:25 <timeless> burn: there may be constraints set here
15:20:37 <timeless> martin__: what makes the 1024x768 in the peer connection
15:20:46 <timeless> ... is that the packets from the video over the wire
15:21:03 <timeless> hta: i'd like to let burn to present 3 more slides
15:21:10 <ekr> ekr has joined #mediacap
15:21:18 <timeless> burn: i didn't say if the tracks were constrained or not
15:21:24 <timeless> [ Next slide ]
15:21:30 <timeless> burn: video source changesresolution
15:21:37 <timeless> ... 1920x1200
15:21:45 <timeless> ... track content may change, sinks still the same
15:21:51 <timeless> [ The Proposal (Expanded)]
15:21:57 <timeless> burn: constraints on tracks, not on sources
15:22:08 <timeless> ... browser does its best to adjust sources to satisfy constraints
15:22:19 <timeless> ... roughly intersecting constraints
15:22:30 <timeless> ... it's the browser's job to satisfy combined constraints set
15:22:38 <timeless> ... constraints can be modified on the Track
15:22:42 <timeless> ... replacing prior constraints
15:22:48 <timeless> ... Tracks can become overconstrained
15:22:55 <timeless> ... 1. when you initially request
15:23:06 <timeless> ... 2. later in process, video source isn't available, or it changes
15:23:18 <timeless> ... in that case, there will be an OverConstrained Event
15:23:21 <timeless> [ Next Slide ]
15:23:25 <timeless> [ Home Client ]
15:23:44 <timeless> video camera w:1024 h:768 fillLightMode: on [at creation ]
15:23:58 <timeless> <video w:800 h>600>
15:24:06 <timeless> <video w:1024 h:768>
15:24:14 <timeless> s/>6/:6/
15:24:27 <timeless> burn: the other track sets a mandatory fillLightMode:off
15:24:39 <timeless> ... it will get an overconstrained event (to the track)
15:24:44 <timeless> ... and the track is muted
15:24:55 <timeless> ekr: how do i recover
15:25:03 <timeless> burn: you the overconstrained track set a handler
15:25:07 <timeless> ... and you set different constraints
15:25:17 <timeless> ekr: do i know which is the problematic constraint?
15:25:29 <timeless> burn: the intent with the current spec is to give you information
15:25:47 <timeless> s/600>/600> N/
15:25:54 <timeless> s/768>/768> P/
15:26:05 <timeless> cullen: if N and P set them both to On
15:26:12 <timeless> ... and then N sets it to off, it will fail?
15:26:15 <timeless> burn: yes
15:26:44 <timeless> cullen: last guy who tries to make an inconsistent change to the resource loses
15:26:55 <timeless> martin__: that doesn't preclude locking discussion from yesterday
15:27:02 <timeless> burn: that's why i asked about between tabs
15:27:08 <timeless> martin__: this would work ok w/in an app
15:27:15 <timeless> ... and ok between tabs in non-exclusive
15:27:23 <timeless> burn: "no required side-effect on source"
15:27:37 <timeless> ... P has a res of 1024x768
15:27:42 <timeless> ... N has res of 800x600
15:27:54 <timeless> ... P was getting nothing
15:27:58 <ekr> ekr has joined #mediacap
15:28:14 <timeless> ... but camera was still generating 1024x768
15:28:24 <timeless> [ Next slide ]
15:28:32 <timeless> burn: there's no requirement that the browser do anything
15:28:44 <timeless> ... but the browser may change camera setting to match remaining sink
15:28:52 <timeless> ... up to browser policy
15:28:56 <timeless> ... permitted but not required
15:29:06 <timeless> martin__: you were concentrating on optimization
15:29:21 <timeless> ... i thought it would end
15:29:23 <timeless> burn: muted
15:29:28 <timeless> Josh_Soref: it matters because it can resume
15:29:41 <timeless> burn: v6 proposal said overconstrained
15:29:54 <timeless> ... caused all tracks to go into an ARM (?) state
15:30:08 <timeless> ... here, the right thing is that the track causing overconstrained to muted
15:30:17 <timeless> martin__: softer, you try to set
15:30:24 <timeless> ... and instead it fails w/o muting
15:30:36 <Travis> Constraint application cannot fail.
15:30:45 <Travis> It is an overlay set of requirements
15:30:51 <wonsuk_> wonsuk_ has joined #mediacap
15:31:15 <timeless> burn: i like that
15:31:20 <timeless> adambe: i like martin__ 's proposal
15:31:25 <timeless> ... that when you set something that doesn't work
15:31:29 <ekr> I also like martin's proposal
15:31:32 <timeless> ... it discards the latest setting and continues
15:31:40 <ekr> also martin_______'s proposal
15:31:43 <timeless> ... when something happens and it isn't something that you did
15:31:47 <timeless> ... when the source changes
15:31:57 <timeless> ... in some cases, it might be nice to pop a constraint
15:32:04 <timeless> burn: say the camera is unplugged
15:32:13 <timeless> ... all your tracks are severely constrained
15:32:25 <timeless> stefanh: aren't they ended?
15:32:30 <timeless> martin__: ignoring shit happens
15:32:43 <timeless> burn: if there's a switch on the camera that's on/off
15:32:56 <timeless> Josh_Soref: it might be a "mute"
15:33:09 <timeless> stefanh: i think we have an onmute event
15:33:19 <timeless> martin__: you may not have software control over mutebutton
15:33:30 <timeless> burn: if something happens in the world
15:33:41 <timeless> ... we need to have a way for things to go to muted
15:33:51 <timeless> ... instead of just going away totally
15:34:09 <timeless> martin__: i don't see any reason not to allow to continue to receive the stream
15:34:14 <timeless> burn: user will see something
15:34:22 <timeless> martin__: you listen for event,
15:34:26 <timeless> ... and if you care, fiddle
15:34:30 <timeless> burn: don't change track
15:34:44 <timeless> [ Coffee Break 15 minutes ]
15:36:16 <dom> dom has joined #mediacap
15:41:08 <lgombos_> lgombos_ has joined #mediacap
15:47:24 <lgombos> lgombos has joined #mediacap
15:47:39 <lgombos> lgombos has joined #mediacap
15:51:38 <lgombos_> lgombos_ has joined #mediacap
15:52:50 <adam> adam has joined #mediacap
15:53:28 <dom> RRSAgent, draft minute
15:53:28 <RRSAgent> I'm logging. I don't understand 'draft minute', dom.  Try /msg RRSAgent help
15:53:29 <dom> RRSAgent, draft minutes
15:53:29 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/06-mediacap-minutes.html dom
15:55:05 <timeless> [ The Proposal (Expanded) ]
15:55:16 <timeless> burn: we have Capabilities, and the current state
15:55:19 <ekr> ekr has joined #mediacap
15:55:31 <timeless> ... capabilities and states are properties of a source
15:55:37 <timeless> ... - not a track
15:55:45 <timeless> ekr: same namespace for keys?
15:55:48 <timeless> burn: yes
15:55:56 <timeless> ... on thing that might change is that Selection v. Control
15:56:07 <timeless> ... for Control case, you might want current state to be on Track and not Source
15:56:13 <timeless> ... your Track might be requiring DSP munging
15:56:44 <timeless> burn: we use the term "released"
15:57:09 <wonsuk> wonsuk has joined #mediacap
15:57:19 <timeless> ... "once a source has been `released` to the application (via permissions, pre-configured allowed, or other) the application will be able to discover additional source-specific capabilities."
15:57:31 <timeless> [ The Other Details ]
15:57:49 <timeless> burn: the constraint registry talks about min-max and enums
15:58:04 <timeless> ... this proposal also includes primary types (strings, ints, float, boolean)
15:58:13 <timeless> ... i'm tempted w/ adjusting the registry
15:58:26 <timeless> ... there are also source ids
15:58:56 <timeless> ... i got a source id the last time i was here and saved it
15:59:45 <timeless> ... you may also be able to get "video", "audio" and the complete set of source ids
15:59:45 <timeless> ... proposal has separate types for audio and video
15:59:45 <timeless> ... and explicit creation of Tracks (not currently possible in gUM)
15:59:51 <timeless> ... this proposal adds an explicit constructor for Audio/Video tracks
15:59:57 <timeless> ... which you then call into gUM
16:00:03 <timeless> [ Proposed (mod of Settings v6) ]
16:00:17 <timeless> burn: it talks about tracks being audio, video, "none"
16:00:28 <timeless> ... that a track can be "readonly" or "remote"
16:00:41 <timeless> ... you can have "readonly" "video", or "remote" "video"
16:00:55 <timeless> ... readonly/remote are other states
16:01:03 <timeless> ... we're not sure exactly how it would be used
16:01:12 <timeless> martin__: not a particularly good answer
16:01:22 <timeless> ... i think you need to go into more about readonly
16:01:32 <timeless> ... if you insert it, you have to justify it
16:01:36 <timeless> burn: Travis inserted it
16:02:37 <timeless> martin__: i can't write video to my camera
16:02:37 <timeless> burn: readonly is intended to mean you can't change settings on a source
16:02:37 <timeless> Josh_Soref: one case is that it's a file stream
16:02:37 <timeless> ... but that discloses it's a file stream
16:02:43 <timeless> martin__: i'm not sure we need it
16:02:56 <timeless> ... if we don't kill the track for applying settings
16:03:00 <timeless> ... then i don't know we need it
16:03:05 <timeless> burn: ok
16:03:09 <timeless> [ About the proposal ]
16:03:18 <timeless> burn: there were a small number of comments to the ML
16:03:25 <timeless> ... it's a long very detailed proposal
16:03:30 <timeless> ... probably very few people read it
16:03:35 <timeless> ... i wanted to talk about it
16:03:48 <timeless> ... stefanh said that the editors would start applying
16:03:55 <timeless> ... but cullen shot it down
16:04:03 <timeless> martin__: since cullen isn't here, i think it's very good
16:04:19 <timeless> stefanh: cullen made that comment after reading the wrong version
16:04:28 <timeless> martin__: there's a huge body of stuff that's very useful
16:04:37 <timeless> ... we can fix up the little bits later
16:04:56 <timeless> burn: i agree, although we need to work out selection v. control
16:04:58 <timeless> ... it's the only thing major enough to work out
16:05:03 <timeless> ekr: 1. is this the right API
16:05:14 <timeless> ... 2. how do we feel about the specific field values
16:05:22 <timeless> ... suggestion is we take these in two stages
16:05:30 <timeless> ... 1. do we think it's the right arch?
16:05:34 <timeless> ... 2. do the list in pieces
16:05:36 <timeless> burn: i agree w/ you
16:05:39 <timeless> ... my plan for today
16:05:43 <timeless> ... was see if we can agree on Arch
16:05:46 <timeless> ... then start applying that
16:06:06 <timeless> ... if we agreed today
16:06:06 <timeless> ... we'd go on to the capabilities list
16:06:11 <timeless> ... not try to agree on things to go in, not even describe all of them
16:06:18 <timeless> ... these are many that have been proposed
16:06:29 <timeless> ... i wanted to poll for levels of interest on these
16:06:36 <timeless> ... to help me order for a start of a discussion
16:06:49 <timeless> [ About the proposal ]
16:07:04 <ekr> ekr has joined #mediacap
16:07:12 <jeromemarcon> jeromemarcon has joined #mediacap
16:07:26 <timeless> burn: open the floor to comments
16:07:26 <timeless> PeterThatcher: lot of comments
16:07:26 <timeless> ... concern that browsers do the same thing
16:07:26 <timeless> s/comments/complexity/
16:07:43 <Travis> It will be very very hard to get exact browser parity when there is wiggle-room in terms of how to handle unconstrained tracks.
16:07:55 <timeless> ... hard to see the browsers doing both right
16:07:55 <timeless> burn: do the same
16:07:55 <timeless> cullen: words i have are "have the same UX"
16:08:09 <timeless> PeterThatcher: has there been consideration for a lower level api?
16:08:16 <timeless> ... less magic in the browser
16:08:20 <timeless> burn: let me speak about history
16:08:33 <timeless> ... discussed for a while
16:08:36 <timeless> ... 2 camps of people
16:08:43 <timeless> ... those who believed the browser should make decissions
16:08:52 <timeless> ... those who believed JS developer should make decissions
16:09:02 <timeless> .... constraints was an attempt to find a middle ground
16:09:09 <timeless> ... let JS developer specify at the level that matters
16:09:15 <timeless> ... and let browsers be wise beyond that
16:09:48 <timeless> ... it seems there's a significant camp who want more control after selection
16:09:48 <timeless> ... that led to the proposal of a settings api
16:09:48 <timeless> s/..../.../
16:09:48 <timeless> ... it's still a settings api for control after selection
16:09:48 <timeless> ... but it still uses constraints language
16:09:53 <dom> dom has joined #mediacap
16:10:30 <timeless> ... so it still gives flexibility
16:10:30 <timeless> ... one other aspect here
16:10:30 <timeless> ... privacy/fingerprinting
16:10:30 <timeless> ... there was concern initially that giving the JS dev direct complete access
16:10:30 <timeless> ... ideally from a App dev
16:10:30 <timeless> ... they want complete list of devices and take absolute control
16:10:35 <timeless> ... we heard from a number of browser devs saying that isn't a good idea
16:10:45 <timeless> ... if we relaxed our notion of what we can give to devs
16:10:53 <timeless> ... or if we came up w/ a permissions set
16:10:57 <timeless> ... to give more control
16:11:06 <timeless> ... i think this is the best compromise of what you give the App dev
16:11:09 <timeless> ... to allow control
16:11:17 <timeless> ... and to let them to be notified when it can't be
16:11:25 <timeless> ... App says "if you don't give me this, i can't run"
16:11:31 <timeless> ... it's a long winded answer
16:11:43 <timeless> jim: Recording also has Capabilities and settings
16:11:48 <timeless> ... Recording doesn't have Constraints
16:11:54 <wonsuk> wonsuk has joined #mediacap
16:11:58 <timeless> burn: what if you have multiple recorders?
16:12:10 <timeless> ... you could say you have constraints but none
16:12:16 <timeless> jesup: you talked about how we got here
16:12:33 <timeless> ... largely fingerprinting and control
16:12:38 <timeless> burn: and selection
16:12:43 <timeless> jesup: before user gives consent
16:12:51 <timeless> ... concerned about giving full details of devices
16:13:02 <timeless> ... propose an alternative solution to that conundrum
16:13:14 <timeless> ... allow JS to have access to device list and capabilities
16:13:22 <timeless> ... within a JS worker with a different origin
16:13:30 <wonsuk> wonsuk has joined #mediacap
16:13:32 <timeless> ... it's constrained to return an output of a sourceid
16:13:42 <timeless> burn: i'll let ekr comment
16:13:55 <timeless> jesup: you rate limit how many times you call it
16:14:04 <timeless> ... to avoid bit yielding
16:14:17 <timeless> ... you remove a very complex hard to make sure it's going to work the same way
16:14:32 <timeless> ... i'm concerned about implementing this and testing it
16:14:40 <timeless> ... and making sure it works in configurations
16:14:47 <timeless> ... i'm tempted to give app writers
16:14:55 <timeless> ... and say to app writers "we have this interface, don't use it"
16:15:23 <timeless> ekr: jesup's proposal could work
16:15:29 <timeless> ... leak of 20-30 bits
16:15:36 <timeless> ... limit to 2 queries per second
16:15:42 <timeless> ... we're done in 8 seconds
16:15:53 <timeless> ... not sure it solves the privacy problem, not sure i care either
16:16:07 <timeless> cullen: i think we're coming up w/ a lot of stuff that works for settings
16:16:17 <timeless> ... dealing w/ tracks and control them once you have access
16:16:25 <timeless> ... the selection part is where we're stumbling more
16:16:30 <timeless> burn: it's been in the document longer
16:16:41 <timeless> cullen: you can see the widespread agreement </sarcasm>
16:16:51 <timeless> ... generally, it's about the user choosing the camera they want
16:17:02 <timeless> ... i wonder whether we should ...
16:17:06 <timeless> ... the privacy history
16:17:09 <timeless> ... i'm becoming
16:17:15 <timeless> ... no one has ever identified attacks
16:17:21 <timeless> ... once you could do Fonts on Canvas
16:17:36 <timeless> ... as we go down this path, i'm trying to understand why we're going down that hole
16:17:40 <timeless> burn: i hear you
16:17:47 <timeless> ... adding settings is more complex than selection
16:17:59 <timeless> ... i don't think we have new arguments against selection different from when we started
16:18:06 <timeless> ... it definitely should make the easy case easy
16:18:09 <timeless> ... that's still easy
16:18:14 <timeless> ... it handles intermediate case nicely
16:18:18 <timeless> ... you don't need device ids
16:18:26 <timeless> ... or a stored database of every camera on the planet
16:18:27 <lgombos> lgombos has joined #mediacap
16:18:35 <timeless> ... i'm nervous about chucking it and starting over
16:18:41 <timeless> martin__: jesup's suggestion
16:18:46 <timeless> ... other than ekr's bits
16:18:52 <timeless> ... means you can't build the UX we're talking about
16:18:56 <timeless> ... w/ a source picker in content
16:19:15 <timeless> ... with the rate limiting of the worker
16:19:53 <timeless> ... on cullen's point, i want to think about it
16:20:04 <timeless> burn: the people arguing for settings control aren't here
16:20:11 <timeless> cullen: the model here for settings seems ok
16:20:20 <timeless> ... but selection seems less understandable
16:20:35 <timeless> ekr: why i like having selection
16:20:40 <timeless> ... 2 working examples in browsers
16:20:48 <timeless> ... Chrome... there's a browser global camera preference
16:20:50 <fluffy> fluffy has joined #mediacap
16:20:52 <timeless> ... do you triage?
16:21:00 <timeless> justin: we pick the global camera pref
16:21:08 <timeless> ekr: firefox prompts you all the time
16:21:20 <timeless> ... 3 models for how selection should work
16:21:24 <timeless> ... #1 it's a browser settings
16:21:30 <timeless> ... #2 it's a user controlled setting
16:21:36 <timeless> ... #3 it's a JS-Browser negotiation
16:21:43 <timeless> s/settings/setting/
16:21:56 <timeless> ... #4 in content selection
16:22:14 <lgombos> lgombos has joined #mediacap
16:22:19 <timeless> ... this quasi magic thing isn't what people want
16:22:32 <wonsuk> wonsuk has joined #mediacap
16:22:36 <timeless> ekr: Control in Chrome, in Content, in neither?
16:22:45 <timeless> ... in content selectors have these privacy risks
16:23:05 <ekr> ekr has joined #mediacap
16:23:18 <timeless> Josh_Soref: it seems like everyone's happy w/ merging Settings in
16:23:26 <timeless> ... but we might want to drop out the Selection bits
16:23:34 <timeless> hta: we have action items about Selection from yesterday
16:23:43 <timeless> ... but today we're talking about Changing Constraints aka "Settings"
16:23:50 <timeless> ... once the line empties
16:23:52 <timeless> ... (if ever)
16:24:09 <fluffy> fluffy has joined #mediacap
16:24:09 <timeless> ... i'd like to call consensus to incorporate this version of settings manipulation into the document
16:24:20 <timeless> ... knowing that how we do selection is still dependent on Action Items from yesterday
16:24:31 <timeless> jesup: i'm sympathetic to that we've put a lot of time into this
16:24:34 <timeless> ... a lot of effort
16:25:55 <timeless> ... you don't really control that
16:26:01 <timeless> ... you can't apply that constraint on a mac
16:26:04 <fluffy> OSX computers will give you whatever resolution you request regardless of capabilities of camera
16:26:32 <timeless> ... "i know from a DB this camera can't do that"
16:26:32 <timeless> ... my concern about selection constraint
16:26:32 <timeless> ... is people will overspecify, locking out the user
16:26:32 <timeless> ... even if it isn't the perfect camera
16:26:40 <timeless> ... i'd like to really understand UCs that drive those
16:26:49 <timeless> ... to override user's ability to choose
16:26:56 <timeless> burn: bad apps can always be written
16:26:57 <lgombos_> lgombos_ has joined #mediacap
16:27:02 <timeless> ... bad apps won't be used for very long
16:27:56 <timeless> Dan_Druta: i'd like more clarity
16:28:02 <timeless> ... no guarantee about control
16:28:33 <timeless> burn: all tracks connected to source receive an overconstrained event
16:28:41 <timeless> ... we had a discussion about different option
16:28:55 <timeless> ... i liked proposal of not killing-muting track and just sending event
16:29:08 <timeless> Dan_Druta: for some it works, for some not
16:29:50 <timeless> ... but js app doesn't have access to this
16:29:53 <Travis> In the v6 proposal, there is actual no "state change" event. So, if no constraints are applied, there would be no notification of source state change (short of polling the state values).
16:30:05 <Travis> (This is probably a missing piece in the v6 proposal).
16:30:16 <timeless> Josh_Soref: the path is disappearing from file content widget
16:30:51 <timeless> ... partially UX and partially security
16:30:51 <timeless> PeterThatcher: we have consensus on Settings
16:30:51 <timeless> ... does that include cropping?
16:30:51 <timeless> hta: we've gotten enough info that cropping -- how to adjust video to fit into boxes
16:30:53 <timeless> ... requires more discussion
16:31:10 <dom> dom: for in-content device selection, couldn't browsers provide a tainted in-content widget that JavaScript couldn't access? similar to the file selector widget
16:32:14 <timeless> ekr: stop improving Chrome
16:32:14 <fluffy> fluffy has joined #mediacap
16:32:16 <timeless> hta: that's life
16:32:19 <timeless> ... Queue is empty
16:32:20 <ekr> it's too awesome already
16:32:25 <timeless> ... show of hands
16:33:13 <timeless> ekr: voting by individual or company
16:33:36 <timeless> ... if i were recording, it would require me to record by company
16:33:45 <timeless> ... if knowing we have an ongoing discussion about:
16:33:48 <timeless> ... A. Selection
16:33:51 <timeless> ... B. Cropping
16:33:57 <timeless> ... C. we haven't discussed specific constraints
16:34:15 <timeless> ... do we have consensus to incorporate the framework of Constraint-Manipulation-After-Selection into the specification?
16:34:31 <Travis> Travis: Yes, we should incorporate!
16:34:44 <timeless> ... if you believe we should incorporate this, at this time
16:34:44 <timeless> ... raise your hand
16:34:53 <timeless> ekr: consequences of yes/no?
16:35:00 <timeless> hta: if you say no, we have to discuss this more later
16:35:06 <timeless> ... and you have to propose changes
16:35:16 <timeless> ... and if not, your proposal for "deleted"
16:35:27 <timeless> ekr: if consensus is yes, a new ED will have this incorporated
16:35:48 <timeless> gmandyam: is this v6 compatible?
16:35:48 <timeless> hta: it will be self-consistent, and similar to v6
16:35:57 <timeless> ... there were a number of minor tweaks between v6 and now
16:36:02 <timeless> ... v6 was impossible to implement
16:36:14 <timeless> cullen: burn presented a number of substantial differences to v6
16:36:16 <timeless> burn: correct
16:36:23 <timeless> ... my goal as an editor in putting this in
16:36:29 <timeless> ... for areas where we don't have consensus
16:36:39 <timeless> ... i'll include a big note that we're still discussing the section
16:36:46 <timeless> ... if i miss something like that, please call me out on it
16:36:52 <timeless> ekr: just wanted to understand that
16:37:01 <timeless> dom: question about integrating it?
16:37:12 <timeless> ... or is it about consensus?
16:37:39 <timeless> Josh_Soref: which work-mode do we have?
16:37:46 <timeless> ... propose, reach consenus, commit
16:37:56 <timeless> ... or put in and then get consensus
16:38:02 <timeless> burn: minor things may not have a note
16:38:07 <timeless> ... major things will have a note until consensu
16:38:16 <timeless> s/consensu/consensus/
16:38:28 <timeless> justin: for things that need more discussion
16:38:34 <timeless> hta: let's do that after this
16:38:43 <timeless> ... if we try to do too many things at once, we won't do any well
16:38:53 <timeless> ... If we think the editing team should incorporate the proposal
16:39:05 <timeless> ... knowing open items
16:39:10 <timeless> [ 16 hands + Travis ]
16:39:19 <timeless> hta: if you oppose, raise your hand now
16:39:23 <timeless> [ 1 hand = justin ]
16:39:31 <timeless> hta: editing team will incorporate as stated
16:39:42 <timeless> ... chairs take an action item to ensure open items are discussed on list
16:39:49 <timeless> cullen: justin, what are your concerns?
16:39:59 <timeless> martin__: i'd like to get justin's opinion
16:40:07 <timeless> ... i'd like editors to mark open issues in the draft
16:40:11 <timeless> burn: that's the intent
16:40:20 <timeless> hta: yes
16:40:23 <ekr> ekr has joined #mediacap
16:40:27 <timeless> justin: all things people want to do
16:40:38 <timeless> ... are all things because they're trying to do these things
16:40:52 <timeless> ... we have all these things
16:40:59 <timeless> ... but we might have many more as we try to do the rest
16:41:04 <timeless> hta: next step is incorporating
16:41:12 <timeless> burn: if it weren't for privacy, we'd be done a long time ago
16:41:25 <timeless> ekr: this spec is far in advance of anything impls have done
16:41:44 <timeless> ... we're going to be finding things we don't understand for quite some time
16:41:45 <timeless> ... because it's so far ahead of what we've done
16:41:51 <timeless> justin: getting stuff working is focus of work
16:41:56 <timeless> ... that list of constraints
16:42:05 <timeless> ... i'd like to make a white list of things we're going to care about
16:42:11 <timeless> burn: that's the next slide
16:42:16 <ekr> ekr has joined #mediacap
16:42:26 <timeless> [ Candidate constraints/states/capabilities ]
16:42:34 <timeless> burn: as an editor, we haven't had specific ones to talk about
16:42:42 <timeless> ... we talk about specifics, it becomes general, it goes back and forth
16:42:49 <timeless> ... i'd like to with the group of people in the room
16:42:52 <timeless> ... not the same as list
16:43:10 <timeless> ... what i'm going to ask
16:43:10 <timeless> ... go through each one, and with a rough idea in your head of what it means
16:43:17 <timeless> ... is it something that might be good to have as a constraint
16:43:23 <timeless> ... to see if there's some breakingpoint
16:43:31 <timeless> ... a big groundswell, v. only a few
16:43:43 <timeless> ... it's input to the editor team for a small candidate initial set
16:43:54 <timeless> justin: for `now` as opposed to `ever`
16:44:01 <timeless> burn: what can be proposed to go into a first draft
16:44:31 <timeless> hta: we're delaying WebRTC until tomorrow morning
16:44:45 <timeless> cullen: take AspectRatio to near Zoom
16:44:53 <timeless> ... do sourceid, width, height, framerate, facingmode
16:45:01 <timeless> burn: i don't want each person to give me their list
16:45:14 <ekr> ekr has joined #mediacap
16:45:15 <timeless> gmandyam: that list is my fault
16:45:24 <timeless> ... it wasn't meant to be for everywhere
16:45:33 <timeless> ... i was satisfied w/ the v6 list
16:45:46 <timeless> ... i hate reopening this debate
16:46:05 <timeless> hta: negotiation isn't between you and Travis isn't consensus of TF
16:46:23 <timeless> burn: Travis's reason for excluding AspectRatio wasn't valid
16:46:31 <timeless> dom: is this about settings or constraints?
16:46:38 <timeless> burn: yes, constraints=settings=capabilities
16:47:09 <timeless> s/settings/states/
16:47:19 <timeless> ... we're only talking about control
16:47:36 <timeless> cullen: how are we doing this?
16:47:40 <timeless> Josh_Soref: hands up, one at a time
16:47:42 <timeless> burn: +1
16:47:58 <timeless> cullen: object to conclusion
16:48:03 <timeless> Josh_Soref: input to the editors
16:48:12 <timeless> burn: a proposal may go to the list, but no change
16:48:30 <timeless> [ sourceId 13 ]
16:48:42 <timeless> [ width 7 ]
16:48:43 <dom> [so people understand what sourceId means in the context of control?]
16:49:02 <timeless> [ height 17 ]
16:49:06 <dom> [but then that's selection, not control]
16:49:07 <timeless> [ aspectRatio 10 ]
16:49:17 <timeless> [ framerate 17 ]
16:49:25 <timeless> [ facingMode 12 ]
16:49:30 <timeless> [ zoom 1 ]
16:49:47 <Travis> dom: sourceID can be applied as a constraint to a track with a different sourceId. That's an overconstrained situation :-)
16:49:48 <timeless> burn: would anyone actually raise their hand for anything after zoom
16:50:12 <timeless> [ Candidate constraints/states/capabilities ]
16:50:15 <dom> Travis, but then that's not one useful to include in the list of control constraints
16:50:16 <timeless> [ sourceId 18 ]
16:50:22 <timeless> [ volume 16 ]
16:50:25 <timeless> [ gain 1 ]
16:50:29 <timeless> burn: thank you
16:50:58 <timeless> dom: Selection is ?
16:50:59 <Travis> dom: The goal being we maintain parity between state, constraints, and capabilities.
16:51:05 <timeless> hta: action item on chairs to take to list
16:51:12 <timeless> [ Lunch ]
16:52:15 <Travis> Folks should spend the time to read the v6 proposal in detail if they haven't had a chance. Thanks!
16:52:33 <fluffy> please join other #webrttc now
16:52:42 <fluffy> uh, that should be #webrtc
16:52:55 <ekr> ekr has joined #mediacap
16:55:03 <dom> RRSAgent, draft minutes
16:55:03 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/06-mediacap-minutes.html dom
16:55:26 <fjh> fjh has joined #mediacap
16:56:25 <adam> adam has joined #mediacap
16:56:51 <jeromemarcon> jeromemarcon has left #mediacap
16:59:43 <mauro> mauro has joined #mediacap
17:18:27 <lgombos_> lgombos_ has joined #mediacap
17:29:44 <lgombos__> lgombos__ has joined #mediacap
17:36:00 <JonLennox> JonLennox has left #mediacap
18:03:10 <fluffy> fluffy has joined #mediacap
18:04:24 <hta> hta has joined #mediacap
18:09:30 <lgombos__> lgombos__ has joined #mediacap
18:27:10 <fluffy> fluffy has joined #mediacap
18:37:27 <adam> adam has joined #mediacap
18:38:12 <dom> dom has joined #mediacap
18:40:57 <lgombos__> lgombos__ has joined #mediacap
18:47:33 <Zakim> Zakim has left #mediacap
18:54:16 <adam> adam has joined #mediacap
19:10:09 <adam> adam has joined #mediacap
19:50:19 <lgombos__> lgombos__ has joined #mediacap
20:00:45 <adam> adam has joined #mediacap
20:37:11 <adam> adam has joined #mediacap
20:51:25 <adam> adam has joined #mediacap
21:09:34 <adam> adam has joined #mediacap
21:53:38 <lgombos> lgombos has joined #mediacap
22:05:07 <lgombos_> lgombos_ has joined #mediacap
22:18:55 <adam> adam has joined #mediacap
22:23:51 <adam> adam has joined #mediacap
22:39:34 <lgombos> lgombos has joined #mediacap