- 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