- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Tue, 10 Dec 2013 10:49:18 +0000
- To: "public-script-coord@w3.org" <public-script-coord@w3.org>
- CC: Harald Alvestrand <hta@google.com>, Dominique Hazael-Massieux <dom@w3.org>
Hi script-coord, the Media Capture TF is developing a to-be recommendation to describe how the web application can get access to, control, and use, input devices such as microphones and cameras [1]. It introduces concepts like - navigator.getUserMedia: ask the user for permission to use cameras and microphones (input devices) - MediaStreamTrack: the control surface for the application related to an input device. - MediaStream: a collection of one or more MediaStreamTracks. Comes really from the fact that the video element plays audio and video so there is a need to collect audio and video MediaStreamTracks intended to be played out together. The APIs are intended to work with the existing media elements, but also with new APIs like the MediaStream Recording API, the real-time communication APIs developed by the WebRTC WG, the WebAudio APIs etc. We'd like your feedback on this document. We would like you to pay particular attention to what is called "constraints" and is specified in section 10 "Constrainable" as this part has been discussed a lot recently. The idea with constraints is to allow the application to control ("constrain") how e.g. a camera is operated. Typical constraints are width and height (in pixels) and framerate. But the constraints are also used with "navigator.getUserMedia" (section 9) to aid the UA to select the best camera for the task when the app asks for a camera. A constraint that is useful in this context is "facingMode", see section 12 for a list of currently defined constraints. The constraints can be used either as "mandatory" or "optional"; and the meaning is that all mandatory constraints must be fulfilled (or the error callback would be invoked) while the UA should do its best to fulfill the optional ones (but that failing to do so is not an error). The design is prepared for adding new constraints in the future, and to allow for UAs to add constraints beyond the ones that must be implemented (i.e. those listed in [1]) are supported. The idea is that if the UA detects a constraint in the mandatory section it does not understand the error callback should be invoked, while if it is in the optional section it would just be ignored. Looking forward to your feedback! Stefan Håkansson for himself and Harald Alvestrand (we're together chairing the Media Capture TF) [1] http://dev.w3.org/2011/webrtc/editor/getusermedia.html
Received on Tuesday, 10 December 2013 10:50:14 UTC