W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2013

Asking for feedback

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>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C415C0F@ESESSMB209.ericsson.se>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC