16:32:27 RRSAgent has joined #mediacap 16:32:27 logging to http://www.w3.org/2014/05/19-mediacap-irc 16:32:31 RRSAgent, make log public 16:32:44 Meeting: Media Capture Task Force F2F 16:32:50 Chair: hta, stefanh 16:33:22 Agenda: https://www.w3.org/wiki/May_19_2014 17:09:30 stefanh has joined #mediacap 17:09:49 The Media Cap meeting will start in about 20 minuts 17:09:59 s/minuts/minutes/ 17:10:22 Remote participation will be through Hangouts 17:12:49 hta has joined #mediacap 17:12:56 To get an invitation to the Hangout session, mail ted.ietf _at_gmail.com 17:26:08 Meeting starting in about 5 minutes 17:26:29 agenda and other stuff at https://www.w3.org/wiki/May_19_2014 17:28:48 gmandyam has joined #mediacap 17:31:22 fluffy has joined #mediacap 17:31:33 hi ? 17:31:42 Hi Cullen 17:31:42 shijun has joined #mediacap 17:31:42 hi cullen! 17:31:51 Ted_ has joined #mediacap 17:31:53 rbarnes has joined #mediacap 17:32:03 DanD has joined #mediacap 17:32:04 ScribeNick: gmandyam 17:32:08 adam has joined #mediacap 17:32:13 burn has joined #mediacap 17:32:28 Minutes last meeting: http://lists.w3.org/Archives/Public/public-media-capture/2014Mar/0176.html 17:32:45 Minutes approved by group 17:32:47 So, I currently see only one remote participant in the Hangout. 17:33:15 adambe has joined #mediacap 17:33:41 suhas has joined #mediacap 17:33:51 Proposed agenda:https://www.w3.org/wiki/May_19_2014 17:34:32 hta went over open request for bugs. Not all bugs will be addressed in the presentation. 17:34:53 -> https://www.w3.org/wiki/File:Bug-processing.pdf Harald's presentation on gUM bugs 17:35:21 Presentation covers bugs that were filed up through Friday, May 16, 2014 17:35:23 jib has joined #mediacap 17:37:04 Bugs broken into 4 categories: Nits (no discussion required), Not specified (missing features - need to decide whether to include), Works Wrong, and Functional Extensions 17:37:53 q? 17:38:24 *Dom, Stefan - can you monitor queue? 17:39:58 q? 17:40:13 Not specified bugs: permissions persistence duration, and "when does the light come on?" 17:41:25 Function extensions: "other" VideoFacingMode, getCapabilities() with no track, event propagation when devices change, separate "access" call, "Ideal" or "tendentious" limit values 17:42:07 Not working: getSettings (asynch vs. sync) 17:42:14 10 minutes of discussion per bug 17:42:49 First issue (Bug 22214): How long do permissions persist? 17:43:11 q+ 17:43:18 q? 17:44:25 Martin: Permissions only persist as long as the web page is part of active browser context (paraphrased - Martin may correct) 17:45:37 juberti: Permissions may also be explicitly turned off, but once light goes off and there are no persistent permissions then the user could be required to re-permit access 17:47:24 ekr: worried about permissions that are not in the user control 17:48:34 ekr: There are two operational modes: one where you get permanent access for any HTTPS site, and one where access is dependent on the RTPpc 17:49:21 juberti: Allowing permissions for HTTP versus only for HTTPS did increase the probability of attack 17:51:36 adambe: Stopping a stream (e.g. unplugging a capture device) results in a MediaStream.stop event, and the user should be re-prompted when this occurs 17:52:08 hta: Hanging up the call (WebRTC) is different from ending the capture stream 17:52:59 ekr: Long-lived sessions (e.g. 3-day FB sessions) should not have persistent permissions 17:53:31 juberti: Users don't trust/pay attention to camera light 17:53:43 q? 17:53:50 juberti: HTTPS could solve the issue of persistent permissions 17:54:37 Ten minutes expired, moving on to next bug 17:55:29 cullen: I propose we do not leave this meeting without solving the permissions model. Maybe we should focus on HTTPS first, and then move on to HTTP. The spec is silent on the topic. 17:56:14 lgombos has joined #mediacap 17:56:29 Bug 22337: When does the light come on? - next topic of discussion 17:57:41 ekr: There are two indicators available: the HW light, and the browser chrome 17:57:58 hta: We are talking about browser chrome - the other stuff is not in our control 17:59:02 ekr: As long as in principle you can reacquire the camera, the browser chrome should provide an indication to the end user 17:59:36 ekr: Only the webpages actively making use of the camera should be indicated to the end user; not the ones who have persistent permissions 17:59:47 q+ 18:00:04 rbarnes has joined #mediacap 18:00:07 q+ 18:00:39 q? 18:00:44 hta: The indicator that a page has acess to the camera is different from an indicator that a page has active access to a capture stream 18:01:07 q? 18:01:25 mt_ has joined #mediacap 18:01:29 q? 18:02:00 Zakim has joined #mediacap 18:02:08 q+ DanD 18:02:10 burn: There may be multiple indicators to the end user. As an end user, if all of those indicators are "off", then I would expect that the capture device would not come on w/o permission. 18:02:29 *adambe, yes 18:02:38 *adambe, feel free to correct 18:03:09 ack DanD 18:03:48 DanD: Indicator should be consistent for each domain. 18:04:34 hta: Reasonable consensus has emerged: indication that permission has been granted, and distinct indication that audio/video is being captured are both important and should be provided by the UI 18:05:09 juberti: MediaStream.stop should turn off the capture indicator 18:05:58 ekr: We need something more than advice, so that browser vendors wil limplement.. 18:06:38 Isseu 22337 18:06:39 Two indicators - one when there is a permission 18:06:40 - one where media is being captured 18:06:41 When you call media stream stop, the capture ligt goes out 18:06:42 Will say MUST indicate. We don’t say how we indicate. 18:07:26 it's media track stop, and the light would only go off if all tracks accessing that source have stopped 18:07:45 Conclusion: Guidance will be provided to browser vendors in specification: provide a UI indication that the permission has been granted, and provide a different UI indication that the capture device is active and the application has access to the MediaStream 18:11:46 martin: Some of the mobile platforms may not be able to display indicators (due to lack of display real estate) 18:15:26 shijun: (1) We should not have any dependencies on the HW light, as this is in the control of the driver, (2) We should consider revoking capture permission when the webpage has received a stop event on the MediaStream 18:16:16 hta: Request to ekr and juberti to come up with a proposal during the coffee break 18:17:13 Bug 25707.25708: Should getSettings() be asynch? 18:17:59 stefanh: We think that they can be obtained synchronously, and recommend closing the bugs 18:18:52 Conclusion: Bugs 25707/25708 will be closed. Settings can be obtained synchronously. 18:20:12 jesup has joined #mediacap 18:20:28 \Bug 23820: Special values in constraints. Idea is to bias constraint selection algm. One proposal is to spec a max value for range bound constraints, and the other is to specify a third "ideal" constraint in addition min/max pair 18:21:15 mreavy has joined #mediacap 18:21:39 jib: These items can be deferred 18:22:11 juberti: max does not fully cover the concepts behind "ideal" 18:22:17 s/jib/jimB/ 18:24:01 martin: Inf can be used to max out the constraint without "ideal" 18:24:34 burn: -Inf usually works for min possible, Inf works for max possible 18:25:15 jib: Inf is rarely desired and is not what apps are designed for; "ideal" solves this problem 18:25:29 q+ 18:25:36 hey q is working , yah 18:25:56 jib: Without ideal, you have to repeat the constraints in ordered sequence going to lower and lower values 18:27:06 cullen: "ideal" is different from a sequence of {max,min}'s. 18:27:33 q+ 18:28:34 cullen: I wonder about the uses for this. :"Ideal" is usually the largest value possible. What are the use cases when ideal is not the max? 18:28:51 "ideal:Infinity" 18:28:58 ekr: Agree. "Ideal" is usually max resolution of camera 18:29:04 q? 18:29:09 q- 18:29:22 ack hta 18:29:25 q+ to respond to an earlier JIB comment 18:30:36 ack burn 18:30:36 burn, you wanted to respond to an earlier JIB comment 18:30:42 JimB: You can query capabilities to get max value; right now if you ask for something out the range it fails. We would have to change spec to allow for non-specific max value 18:31:51 juberti: We would like to avoid "advanced" constraints 18:32:20 burn: This is too much to add to the spec at this point 18:33:51 jib: WebIDL has Inf/-Inf. So we may already have a way to express indeterminate max and min. There is an expectation however that the max end of range will always be allocated, while the browser may allocate the midpoint. "Ideal" addresses this issue. 18:34:28 Zakim, zap anyone coming to join the queue 18:34:28 I don't understand 'zap anyone coming to join the queue', dom 18:34:36 jib: Firefox can also implement ordered constraints if "ideal" is not adopted. 18:36:56 lgombos has joined #mediacap 18:37:18 juberti: There are capture cards that only provide fixed res, but "ideal" will allow you to operate even if a lowered res is desired 18:37:48 jib has joined #mediacap 18:37:52 cullen: I propose that at the coffee break I work offline with jib and any other interested parties to incorporate "ideal" 18:38:05 hta: Include burn too 18:38:48 martin: There are a number of cases where the no. of pixels on the other end (WebRTC) are less than what the local capture device produces. Then "ideal" would not match max. 18:39:53 I think ideal should be added 18:40:07 The chair then put forward in infomal poll: (1) Do you have enough info to make a decision? (2) Do you think "ideal" should be added? (3) Do you think "ideal" should not be added? 18:40:34 1: yes, 2: yes, 3: no 18:41:13 More than half the room was ready to make a decision. About 20 persons felt "ideal" should be added, and that 2 persons felt that "ideal" should not be added. Therefore there was no consensus detected in the room. 18:41:36 s/no consensus/no smooth consensus/ (there was rough consensus) 18:41:49 Martin requested that the persons who voted against "ideal" make their concerns known. 18:41:58 s/no consensus/no smooth consensus/ 18:42:14 burn: The "advanced" list enables more than what "ideal" does. 18:42:44 JimB: I don't think we need to add "ideal" now, because "advanced" accomplishes what is required 18:43:03 Conclusion: No smooth consensus. Issue unesolved. 18:43:32 Bug 25298: VideoFacingMode for other directions (i.e. "other") 18:43:53 I think "Dangerously underspecified" as a value. 18:44:02 hta: enum values in WebIDL are not easily extensible 18:44:31 Possible JS representations (acc. to hta slides): "unknown" or "other" 18:44:54 jib: Unknown values in WebIDL-complian enums end up in thrown exceptions 18:47:03 jib: Agreeing w/Justin: "other" and "unknown" are different. Absence of a dictionary member should be "unknown" 18:47:21 jib" "other" would be a JS undefined 18:47:32 jib: "other" would be a JS undefined 18:49:48 jib: We could use a DOMString instead of an enum for future proofing, but the JS undefined will be returned for other/unknown directions 18:50:06 s/what "ideal" does./what "ideal" does, and there have been many statements claiming that none of the "ideal" use cases cannot be accomplished with the existing syntax, which is just not true./ 18:50:37 cullen: An undefined value can get into SDP, which could be problematic 18:51:42 Action item for jib: Write up proposed change 18:51:42 Error finding 'item'. You can review and register nicknames at . 18:52:53 Conclusion: VideoFacingMode is no longer an enum - it is a DOMString 18:53:39 Bug 25247: GetCapabilities w/o a track 18:53:59 hta: Would be nice to know what is possible to call w/o fist calling gUM 18:54:16 Martin: We don't solve this problem 18:54:45 dom: Agree with Martin - fingerprinting is a concern. 18:55:12 JimB: Agree with Dom and Martin. Have an enumerate devices call instead. 18:55:19 COnclusion: We don't do this. Close the bug. 18:55:38 s/Agree with Martin/what I understand Martin was summarizing/ 18:56:07 yes! 18:56:13 correction from earlier: "unknown" would be JS undefined 18:56:17 Bug 24015: Event to signal when devices have changed 18:56:32 Yes == yes we want en event for device plugged/unplugged 18:56:51 hta: Would track when devices are plugged or unplugged 18:57:37 hta: We don't have an event target that can track this. 18:57:51 Conclusion: Add an event to listed for device changes 18:58:12 Bug 23128: "get access" call 18:58:22 The bug was closed, but should it be revisited? 18:58:34 I want to create a MediaStream with a video track from a Canvas, and tell it to capture frames either by telling it "capture now", or (maybe) by setting a delta time between async captures (though one could do it through setTimeout) 18:58:49 I was going to write something up, but ran out of time 18:59:31 dom: This is complicated. I recommend keeping it closed. Also, the problem is more generic than just media capture. 19:00:06 dom: There is some ongoing work on permissions management in the W3C. Recommend living with the specification as is. 19:00:52 Conclusion: Bug remains closed 19:01:15 I may try to piggyback this on Martin's presentation :-) 19:02:04 cullen: Propose that we don't discuss Recording right away. Open bugs should be prioritized. 19:04:53 Moving on to Recording API. Bug topic closed. No change in agenda. 19:05:38 Recording API: https://dvcs.w3.org/hg/dap/raw-file/default/media-stream-capture/MediaRecorder.html 19:05:47 https://dvcs.w3.org/hg/dap/raw-file/default/media-stream-capture/MediaRecorder.html 19:07:26 JimB introduces API. start() is the basic record method, with optional timeslice parameter. 19:07:29 Topic: MediaRecorder API 19:08:15 JimB; There are onerror and onwarning events. onwarning events have not been well-justified, so recommend removal. 19:09:08 juberti: Agreed with removal of onwarning. 19:09:43 Martin: Warnings are not programatically actionable, so agree with removal. Also, Mozilla does not currently implement anways. 19:11:16 JimB: Is MIME type sufficient for recordng? {Most of the room felt the answer to this is no} 19:13:19 juberti: Recording options should match the track resolution 19:14:10 gmandyam: This was meant to address native media recorders on handheld devices which only offer up fixed resolutions 19:14:47 juberti: Bit rate of recording should be under the app control. 19:15:33 Recording API conclusion: MimeType and bit rate are required for MediaRecorder constraints 19:15:44 q+ 19:16:47 hta: This is not sufficient. we need an indication of 'seekability' 19:17:12 cullen: It may be enough to find out what the format is, not to control it 19:17:26 JimB: This is why it is constrainable 19:17:39 juberti: Doohickeys may be a solution to this 19:18:42 Roman: Does MIME type include parameters (answer was yes) 19:19:01 ack gmandyam 19:20:20 q? 19:24:05 Roman: How is timeslice defined (paraphrased)? {Answer is this is clock time, not audio time} 19:24:25 JimB: There has been no MTI codec defined for recording 19:24:42 martin: Recommend avoiding this topic of MTI codecs for recording 19:25:42 Summary of conclusions for Recording API: Get rid of onwarning, constrants include bitrate and MIME type 19:28:04 juberti: onstart, onpause, etc. can be collapsed into a state change event handler 19:29:07 dom: We should look at other similar specs before going forward with this before going with an onstatechange event handler 19:29:44 juberti: WebRTC has onstatechange, but MediaStream has onstarted/onended 19:30:42 A foolish consistency is the hobgoblin of little minds,... 19:58:29 rbarnes has joined #mediacap 20:03:51 rbarnes has joined #mediacap 20:06:18 jib has joined #mediacap 20:06:20 suhas has joined #mediacap 20:07:53 juberti has joined #mediacap 20:07:54 scribenick: juberti 20:08:48 mt_: Can you handwave about adding mediastream = canvas.captureStream(), and then either strobing it (canvas.captureFrame()?) or setting a periodic sampling (canvas.captureFramePeriod() or Timeout() or whatever) 20:09:06 along with the media.captureStream* stuff 20:09:32 cullen: will propose simplification of constraints stuff 20:09:47 ... ideal allows us to really simplify something that has grown overcomplicated 20:10:07 martin: when 20:10:14 cullen: august 15 20:10:40 martin: seriously? 20:11:16 cullen: lots of stuff in flight 20:11:24 hta: that's not reasonable. 20:11:43 cullen: it will be done well before the WG agrees to the permission model. 20:12:46 stefanhak: what were the results of the breakout on this topic? 20:13:01 burn: some folks were supportive of ideal 20:13:12 cullen: I preferred the syntax of 3 weeks ago. 20:14:06 cullen: I think others prefer it as well. 20:14:21 ... I would be willing to propose something before IETF about this 20:14:34 stefanhak: what about permissions? 20:14:54 martin: discussed what does it mean for an app to disconnect a stream while retaining access to the stream? 20:15:29 martin: through some mechanism, the app could release the track, but retain permission 20:15:42 ... we'd need a way to have separate indicators for having access to media and capturing media 20:16:03 ... .enabled could be one way to do this 20:16:16 cullen: if this happens, the light will go off? 20:16:55 martin: yes, the light going off is the end of the indicator for capturing media 20:16:58 q+ 20:17:08 ... but there will be another indicator for permission to capture media 20:17:24 ... only when you call stop, and the track ends, would that permission go away 20:17:44 ... we also discovered some other significant problems that we need to deal with 20:17:51 ... (later) 20:18:06 cullen: what about a delay to the indicator turning off? 20:18:27 martin: yes, we left that as something we can say about the capture indicator 20:18:34 ekr: that should be left to indicators 20:18:49 ekr: security requirements only should go into the draft 20:19:13 martin: don't want a drive-by capturing a single frame 20:19:38 ekr: needs to be noticeable, leave it to the implementors to figure this out 20:20:28 Latest version of Image Capture spec: http://gmandyam.github.io/image-capture/ 20:20:54 juberti: to be clear, .enabled wasn't agreed upon. But we did agree there needs to be a way to release the capture but not the permission 20:22:25 gmandyam: image capture API for photo taking applications 20:22:45 ... provides a means to set camera settings, not usually available on a webcam 20:22:54 ... also provides two methods for taking a photo, called... 20:23:00 ... takePhoto, and... 20:23:31 ... grabFrame, which returns a raw buffer, allowing JS image processing 20:23:35 ... (takePhoto returns JPG) 20:24:56 ... let's talk about settings... last discussed in 2013 TPAC 20:25:11 ... zoom - group didn't want this as constraint 20:25:32 ... other new setting is autofocus 20:26:31 ... open issue - how to deal with non-autofocus cases 20:26:50 juberti: is this specific to image capture cases (i.e. not MSRecorder or PC?) 20:26:56 gmandyam: yes 20:27:30 gmandyam: TPAC 2013 - agreed on camera preview MediaStream - no special security properties 20:27:56 ... takePhoto has been proposed as Promise-based method 20:28:07 ... no arguments against it 20:28:36 ... designed ImageCapture as an overloaded object to allow use of promise-based methods 20:28:48 .. setOptions and onoptions event handler reamin 20:29:28 dom: does it make sense to have two interfaces? 20:29:47 ... think image capture makes sense to be promise-based 20:31:19 ... I think a promise when you have a single callback make sense, and event when you have multiple callbacks 20:32:12 shijun: device may have multiple pins. videopin is 1080p, image is 20M 20:32:40 ... what does API say about this? 20:33:57 gmandyam: originally there were two modes - high fps for video, low fps for photo 20:34:13 ... now we have a single MS that can go to PeerConnection or be used for taking photos 20:35:00 ... we'll have that which can be used for preview stream, but we should be able to capture from the hi-res, low fps bin 20:35:14 s/bin/pin 20:35:32 shijun: I think there may be problems 20:35:48 gmandyam: Who is implementing? 20:36:09 ... not in IE 11, Blink. Mozilla has committed to takePhoto 20:36:22 ... any remaining questions? 20:37:00 pthatcher: terminology question: why photo in some places, and image on others? 20:37:03 s/on/in 20:37:20 gmandyam: no opposition 20:37:36 pthatcher: suggest replacing photo with image 20:37:43 gmandyam: sure, will take to mailing list 20:38:43 ekr: the problem we realized - changing camera from front to back 20:39:04 ... removeStream(frontCam), addStream(backCam) 20:39:38 cullen: use case: want to switch cams while recording 20:39:45 I desparately want to be able to change cameras without onnegotiationneeded firing 20:39:46 martin: I have a solution for that 20:39:54 mt_: ^ 20:40:08 martin has a solution for cullen, not jesup 20:40:15 -> https://www.w3.org/wiki/images/2/2d/Martin-slides.pdf Martin's slides 20:41:46 martin: discussing captureStreamUntilEnded and captureStream 20:41:47 I have some comments to make if I can have the floor after Martin, if he doesn't cover what I wanted to mention (track switching, and mediastream capture from canvas). He may cover it, so I'll wait to see 20:42:23 ... the idea is to create a media stream from the contents of a