2. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, NOT REQUIRED, and SHOULD are to be interpreted as described in [RFC2119].

This specification defines conformance criteria that apply to a single product: the User Agent that implements the interfaces that it contains.

Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)

Implementations that use ECMAScript [ECMA-262] to implement the APIs defined in this specification must implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [ WEBIDL-1], as this specification uses that specification and terminology.

3. Terminology

HTML Terms:

The EventHandler interface represents a callback used for event handlers as defined in [ HTML52].

The concepts queue a task and fires a simple event are defined in [HTML52].

The terms event handlers and responsible document are defined in [HTML52].

The term current settings object is defined in [HTML52].

The term allowed to use is defined in [HTML52].

DOMException

The term DOMException is defined in WebIDL [ WEBIDL-1]

source

A source is the "thing" providing the source of a media stream track. The source is the broadcaster of the media itself. A source can be a physical webcam, microphone, local video or audio file from the user's hard drive, network resource, or static image. Note that this document describes the use of microphone and camera type sources only, the use of other source types is described in other documents.

An application that has no prior authorization regarding sources is only given the number of available sources, their type and any relationship to other devices. Additional information about sources can become available when applications are authorized to use a source (see 9.2.1 Access control model).

Sources do not have constraints — tracks have constraints. When a source is connected to a track, it must produce media that conforms to the constraints present on that track. Multiple tracks can be attached to the same source. User Agent processing, such as downsampling, MAY be used to ensure that all tracks have appropriate media.

Sources have constrainable properties which have capabilities and settings. The constrainable properties are "owned" by the source and are common to any (multiple) tracks that happen to be using the same source (e.g., if two different track objects bound to the same source ask for the same capability or setting information, they will get back the same answer).

Setting (Source Setting)

A setting refers to the immediate, current value of the source's constrainable properties. Settings are always read-only.

A source's settings can change dynamically over time due to environmental conditions, sink configurations, or constraint changes. A source's settings must always conform to the current set of basic (mandatory) constraints on all attached tracks. A source that cannot conform to these constraints causes affected tracks to become overconstrained and therefore muted. A User Agent attempts to ensure that sources adhere to advanced (optional) constraints as closely as possible, see 11. Constrainable Pattern.

Although settings are a property of the source, they are only exposed to the application through the tracks attached to the source. This is exposed via the ConstrainablePattern interface.

Capabilities

For each constrainable property, there is a capability that describes whether it is supported by the source and if so, the range of supported values. As with settings, capabilities are exposed to the application via the ConstrainablePattern interface.

The values of the supported capabilities must be normalized to the ranges and enumerated types defined in this specification.

A getCapabilities() call on a track returns the same underlying per-source capabilities for all tracks connected to the source.

Source capabilities are effectively constant. Applications should be able to depend on a specific source having the same capabilities for any browsing session.

This API is intentionally simplified. Capabilities are not capable of describing interactions between different values. For instance, it is not possible to accurately describe the capabilities of a camera that can produce a high resolution video stream at a low frame rate and lower resolutions at a higher frame rate. Capabilities describe the complete range of each value. Interactions between constraints are exposed by attempting to apply constraints.

Constraints

Constraints provide a general control surface that allows applications to both select an appropriate source for a track and, once selected, to influence how a source operates.

Constraints limit the range of operating modes that a source can use when providing media for a track. Without provided track constraints, implementations are free to select a source's settings from the full ranges of its supported capabilities. Implementations may also adjust source settings at any time within the bounds imposed by all applied constraints.

getUserMedia() uses constraints to help select an appropriate source for a track and configure it. Additionally, the ConstrainablePattern interface on tracks includes an API for dynamically changing the track's constraints at any later time.

A track will not be connected to a source using getUserMedia() if its initial constraints cannot be satisfied. However, the ability to meet the constraints on a track can change over time, and constraints can be changed. If circumstances change such that constraints cannot be met, the ConstrainablePattern interface defines an appropriate error to inform the application. 5. The model: sources, sinks, constraints, and settings explains how constraints interact in more detail.

In general, User Agents will have more flexibility to optimize the media streaming experience the fewer constraints are applied, so application authors are strongly encouraged to use mandatory constraints sparingly.

For each constrainable property, a constraint exists whose name corresponds with the relevant source setting name and capability name.

RTCPeerConnection

RTCPeerConnection is defined in [ WEBRTC10].

Permissions

The terms permission, retrieve the permission state, request permission and create a permission storage entry are defined in [permissions].

Note

"request permission" isn't defined yet. Filed as permissions issue 62.

4. MediaStream API

[Exposed=Window,
 Constructor,
 Constructor(MediaStream stream),
 Constructor(sequence<MediaStreamTrack> tracks)]
interface MediaStream : EventTarget {
    readonly attribute DOMString    id;
    sequence<MediaStreamTrack> getAudioTracks();
    sequence<MediaStreamTrack> getVideoTracks();
    sequence<MediaStreamTrack> getTracks();
    MediaStreamTrack?          getTrackById(DOMString trackId);
    void                       addTrack(MediaStreamTrack track);
    void                       removeTrack(MediaStreamTrack track);
    MediaStream                clone();
    readonly attribute boolean      active;
             attribute EventHandler onaddtrack;
             attribute EventHandler onremovetrack;
};

[Exposed=Window]
interface MediaStreamTrack : EventTarget {
    readonly attribute DOMString             kind;
    readonly attribute DOMString             id;
    readonly attribute DOMString             label;
             attribute boolean               enabled;
    readonly attribute boolean               muted;
             attribute EventHandler          onmute;
             attribute EventHandler          onunmute;
    readonly attribute MediaStreamTrackState readyState;
             attribute EventHandler          onended;
    MediaStreamTrack       clone();
    void                   stop();
    MediaTrackCapabilities getCapabilities();
    MediaTrackConstraints  getConstraints();
    MediaTrackSettings     getSettings();
    Promise<void>          applyConstraints(optional MediaTrackConstraints constraints);
             attribute EventHandler          onoverconstrained;
};

enum MediaStreamTrackState {
    "live",
    "ended"
};

dictionary MediaTrackSupportedConstraints {
    boolean width = true;
    boolean height = true;
    boolean aspectRatio = true;
    boolean frameRate = true;
    boolean facingMode = true;
    boolean volume = true;
    boolean sampleRate = true;
    boolean sampleSize = true;
    boolean echoCancellation = true;
    boolean autoGainControl = true;
    boolean noiseSuppression = true;
    boolean latency = true;
    boolean channelCount = true;
    boolean deviceId = true;
    boolean groupId = true;
};

dictionary MediaTrackCapabilities {
    LongRange           width;
    LongRange           height;
    DoubleRange         aspectRatio;
    DoubleRange         frameRate;
    sequence<DOMString> facingMode;
    DoubleRange         volume;
    LongRange           sampleRate;
    LongRange           sampleSize;
    sequence<boolean>   echoCancellation;
    sequence<boolean>   autoGainControl;
    sequence<boolean>   noiseSuppression;
    DoubleRange         latency;
    LongRange           channelCount;
    DOMString           deviceId;
    DOMString           groupId;
};

dictionary MediaTrackConstraints : MediaTrackConstraintSet {
    sequence<MediaTrackConstraintSet> advanced;
};

dictionary MediaTrackConstraintSet {
    ConstrainLong      width;
    ConstrainLong      height;
    ConstrainDouble    aspectRatio;
    ConstrainDouble    frameRate;
    ConstrainDOMString facingMode;
    ConstrainDouble    volume;
    ConstrainLong      sampleRate;
    ConstrainLong      sampleSize;
    ConstrainBoolean   echoCancellation;
    ConstrainBoolean   autoGainControl;
    ConstrainBoolean   noiseSuppression;
    ConstrainDouble    latency;
    ConstrainLong      channelCount;
    ConstrainDOMString deviceId;
    ConstrainDOMString groupId;
};

dictionary MediaTrackSettings {
    long      width;
    long      height;
    double    aspectRatio;
    double    frameRate;
    DOMString facingMode;
    double    volume;
    long      sampleRate;
    long      sampleSize;
    boolean   echoCancellation;
    boolean   autoGainControl;
    boolean   noiseSuppression;
    double    latency;
    long      channelCount;
    DOMString deviceId;
    DOMString groupId;
};

enum VideoFacingModeEnum {
    "user",
    "environment",
    "left",
    "right"
};

[Exposed=Window,
 Constructor(DOMString type, MediaStreamTrackEventInit eventInitDict)]
interface MediaStreamTrackEvent : Event {
    [SameObject]
    readonly attribute MediaStreamTrack track;
};

dictionary MediaStreamTrackEventInit : EventInit {
    required MediaStreamTrack track;
};

6. MediaStreams in Media Elements

A MediaStream may be assigned to media elements. A MediaStream is not preloadable or seekable and represents a simple, potentially infinite, linear media timeline. The timeline starts at 0 and increments linearly in real time as long as the MediaStream is playing. The timeline does not increment when the playout of the MediaStream is paused.

User Agents that support this specification MUST support the srcObject attribute of the HTMLMediaElement interface defined in [HTML52], which includes support for playing MediaStream objects.

The [HTML52] document outlines how the HTMLMediaElement works with a media provider object. The following applies when the media provider object is a MediaStream :

• Whenever an [HTML52] AudioTrack or a VideoTrack is created, the id and label attributes must be initialized to the corresponding attributes of the MediaStreamTrack, the kind attribute must be initialized to "main" and the language attribute to the empty string

• The User Agent MUST always play the current data from the MediaStream and MUST NOT buffer.

• Since the order in the MediaStream 's track set is undefined, no requirements are put on how the AudioTrackList and VideoTrackList is ordered

• When the MediaStream state moves from the active to the inactive state, the User Agent MUST raise an ended event on the HTMLMediaElement and set its ended attribute to true. Note that once ended equals true the HTMLMediaElement will not play media even if new MediaStreamTrack 's are added to the MediaStream (causing it to return to the active state) unless autoplay is true or the web application restarts the element, e.g., by calling play()

• Any calls to the fastSeek method on a HTMLMediaElement must be ignored

The nature of the MediaStream places certain restrictions on the behavior and attribute values of the associated HTMLMediaElement and on the operations that can be performed on it, as shown below:

7. Error Handling

This section and its subsections extend the list of Error subclasses defined in [ES6] following the pattern for NativeError in section 19.5.6 of that specification. Assume the following:

• that use of syntax such as [[something]] and %something% is as used in [ES6].
• that the rules for ECMAScript standard built-in objects ([ES6], section 17) are in effect in this section.
• that the new intrinsic objects %OverconstrainedError% and %OverconstrainedErrorPrototype% are available as if they had been included in ([ES6], Table 7) and all referencing sections, e.g. ([ ES6], section 8.2.2), thus behave appropriately.

[Exposed=Window,
 Constructor(DOMString type, OverconstrainedErrorEventInit eventInitDict)]
interface OverconstrainedErrorEvent : Event {
    readonly attribute OverconstrainedError? error;
};

dictionary OverconstrainedErrorEventInit : EventInit {
    OverconstrainedError? error = null;
};

9. Enumerating Local Media Devices

This section describes an API that the script can use to query the User Agent about connected media input and output devices (for example a web camera or a headset).

[Exposed=Window,
 NoInterfaceObject]
interface NavigatorUserMedia {
    [SameObject]
    readonly attribute MediaDevices mediaDevices;
};

Navigator implements NavigatorUserMedia;

[Exposed=Window]
interface MediaDevices : EventTarget {
    attribute EventHandler ondevicechange;
    Promise<sequence<MediaDeviceInfo>> enumerateDevices();
};

[Exposed=Window]
interface MediaDeviceInfo {
    readonly attribute DOMString       deviceId;
    readonly attribute MediaDeviceKind kind;
    readonly attribute DOMString       label;
    readonly attribute DOMString       groupId;
    [Default] object toJSON();
};

enum MediaDeviceKind {
    "audioinput",
    "audiooutput",
    "videoinput"
};

interface InputDeviceInfo : MediaDeviceInfo {
    MediaTrackCapabilities getCapabilities();
};

10. Obtaining local multimedia content

This section extends NavigatorUserMedia and MediaDevices with APIs to request permission to access media input devices available to the User Agent.

Alternatively, a local MediaStream can be captured from certain types of DOM elements, such as the video element [ mediacapture-fromelement]. This can be useful for automated testing.

When on an insecure origin [mixed-content], User Agents are encouraged to warn about usage of navigator.mediaDevices.getUserMedia, navigator.getUserMedia, and any prefixed variants in their developer tools, error logs, etc. It is explicitly permitted for User Agents to remove these APIs entirely when on an insecure origin, as long as they remove all of them at once (e.g., they should not leave just the prefixed version available on insecure origins).

partial interface NavigatorUserMedia {
    void getUserMedia(MediaStreamConstraints constraints,
                      NavigatorUserMediaSuccessCallback successCallback,
                      NavigatorUserMediaErrorCallback errorCallback);
};

partial interface MediaDevices {
    MediaTrackSupportedConstraints getSupportedConstraints();
    Promise<MediaStream>           getUserMedia(optional MediaStreamConstraints constraints);
};

dictionary MediaStreamConstraints {
    (boolean or MediaTrackConstraints) video = false;
    (boolean or MediaTrackConstraints) audio = false;
};

callback NavigatorUserMediaSuccessCallback = void (MediaStream stream);

callback NavigatorUserMediaErrorCallback = void (MediaStreamError error);

typedef object MediaStreamError;

11. Constrainable Pattern

The Constrainable pattern allows applications to inspect and adjust the properties of objects implementing it (the constrainable object). It is broken out as a separate set of definitions so that it can be referred to by other specifications. The core concept is the Capability, which consists of a constrainable property of an object and the set of its possible values, which may be specified either as a range or as an enumeration. For example, a camera might be capable of framerates (a property) between 20 and 50 frames per second (a range) and may be able to be positioned (a property) facing towards the user, away from the user, or to the left or right of the user (an enumerated set). The application can examine a constrainable property's supported Capabilities via the getCapabilities() accessor.

The application can select the (range of) values it wants for an object's Capabilities by means of basic and/or advanced ConstraintSets and the applyConstraints() method. A ConstraintSet consists of the names of one or more properties of the object plus the desired value (or a range of desired values) for each property. Each of those property/value pairs can be considered to be an individual constraint. For example, the application may set a ConstraintSet containing two constraints, the first stating that the framerate of a camera be between 30 and 40 frames per second (a range) and the second that the camera should be facing the user (a specific value). How the individual constraints interact depends on whether and how they are given in the basic Constraint structure, which is a ConstraintSet with an additional 'advanced' property, or whether they are in a ConstraintSet in the advanced list. The behavior is as follows: all 'min', 'max', and 'exact' constraints in the basic Constraint structure are together treated as the 'required' set, and if it is not possible to satisfy simultaneously all of those individual constraints for the indicated property names, the User Agent MUST reject the returned promise. Otherwise, it must apply the required constraints. Next, it will consider any ConstraintSets given in the 'advanced' list, in the order in which they are specified, and will try to satisfy/apply each complete ConstraintSet (i.e., all constraints in the ConstraintSet together), but will skip a ConstraintSet if and only if it cannot satisfy/apply it in its entirety. Next, the User Agent MUST attempt to apply, individually, any 'ideal' constraints or a constraint given as a bare value for the property. Of these properties, it MUST satisfy the largest number that it can, in any order. Finally, the User Agent MUST resolve the returned promise.

The following examples may help to understand how constraints work. The first shows a basic Constraint structure. Three constraints are given, each of which the User Agent will attempt to satisfy individually. Depending upon the resolutions available for this camera, it is possible that not all three constraints can be satisfied at the same time. If so, the User Agent will satisfy two if it can, or only one if not even two constraints can be satisfied together. Note that if not all three can be satisfied simultaneously, it is possible that there is more than one combination of two constraints that could be satisfied. If so, the User Agent will choose.

var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["aspectRatio"]) {
  // Treat like an error.
}
 var constraints =
  {
width: 1280,
height: 720,
aspectRatio: 1.5
  };

This next example adds a small bit of complexity. The ideal values are still given for width and height, but this time with minimum requirements on each as well as a minimum frameRate that must be satisfied. If it cannot satisfy the frameRate, width or height minimum it will reject the promise. Otherwise, it will try to satisfy the width, height, and aspectRatio target values as well and then resolve the promise. Note that the frameRate minimum might be within the capabilities of the camera and satisfiable in ideal lighting conditions, but not in low light, and could therefore result in firing of the onoverconstrained event handler under poor lighting conditions.

var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["aspectRatio"] || !supports["frameRate"]) {
  // Treat like an error.
}
 var constraints =
  {
frameRate: {min: 20},
width: {min: 640, ideal: 1280},
height: {min: 480, ideal: 720},
aspectRatio: 1.5
  };

This example illustrates the full control possible with the Constraints structure by adding the 'advanced' property. In this case, the User Agent behaves the same way with respect to the required constraints, but before attempting to satisfy the ideal values it will process the 'advanced' list. In this example the 'advanced' list contains two ConstraintSets. The first specifies width and height constraints, and the second specifies an aspectRatio constraint. Note that in the advanced list, these bare values are treated as 'exact' values. This example represents the following: "I need my video to be at least 640 pixels wide and at least 480 pixels high. My preference is for precisely 1920x1280, but if you can't give me that, give me an aspectRatio of 4x3 if at all possible. If even that is not possible, give me a resolution as close to 1280x720 as possible."

var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["width"] || !supports["height"]) {
  // Treat like an error.
}
 var constraints =
  {
width: {min: 640, ideal: 1280},
height: {min: 480, ideal: 720},
advanced: [{width: 1920, height: 1280},
           {aspectRatio: 1.3333333333}]
  };

The ordering of advanced ConstraintSets is significant. In the preceding example it is impossible to satisfy both the 1920x1280 ConstraintSet and the 4x3 aspect ratio ConstraintSet at the same time. Since the 1920x1280 occurs first in the list, the User Agent will attempt to satisfy it first. Application authors can therefore implement a backoff strategy by specifying multiple advanced ConstraintSets for the same property. For example, an application might specify three advanced ConstraintSets, the first asking for a frame rate greater than 500, the second asking for a frame rate greater than 400, and the third asking for one greater than 300. If the User Agent is capable of setting a frame rate greater than 500, it will (and the subsequent two ConstraintSets will be trivially satisfied). However, if the User Agent cannot set the frame rate above 500, it will skip that ConstraintSet and attempt to set the frame rate above 400. If that fails, it will then try to set it above 300. If the User Agent cannot satisfy any of the three ConstraintSets, it will set the frame rate to any value it can get. If the developers wanted to insist on 300 as a lower bound, they could provide that as a 'min' value in the basic ConstraintSet. In that case, the User Agent would fail altogether if it couldn't get a value over 300, but would choose a value over 500 if possible, then try for a value over 400.

Note that, unlike basic constraints, the constraints within a ConstraintSet in the advanced list must be satisfied together or skipped together. Thus, {width: 1920, height: 1280} is a request for that specific resolution, not a request for that width or that height. One can think of the basic constraints as requesting an 'or' (non-exclusive) of the individual constraints, while each advanced ConstraintSet is requesting an 'and' of the individual constraints in the ConstraintSet. An application may inspect the full set of Constraints currently in effect via the getConstraints() accessor.

The specific value that the User Agent chooses for a constrainable property is referred to as a Setting. For example, if the application applies a ConstraintSet specifying that the frameRate must be at least 30 frames per second, and no greater than 40, the Setting can be any intermediate value, e.g., 32, 35, or 37 frames per second. The application can query the current settings of the object's constrainable properties via the getSettings() accessor.

[NoInterfaceObject]
interface ConstrainablePattern {
    Capabilities  getCapabilities();
    Constraints   getConstraints();
    Settings      getSettings();
    Promise<void> applyConstraints(optional Constraints constraints);
    attribute EventHandler onoverconstrained;
};

var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["facingMode"]) {
  // Treat like an error.
}
var constraints = {
  width: {
    min: 640
  },
  height: {
    min: 480
  },
  advanced: [{
width: 650
    }, {
width: {
  min: 650
}
    }, {
frameRate: 60
    }, {
width: {
  max: 800
}
    }, {
facingMode: "user"
    }]
};

var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["deviceId"]) {
  // Treat like an error.
}
var constraints = {
  deviceId: {exact: "20983-20o198-109283-098-09812"},
  advanced: [{
width: {
  min: 800,
  max: 1200
}
    }, {
height: {
  min: 600
}
    }]
};

var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["deviceId"] || !supports["volume"]) {
  // Treat like an error.
}
var constraints = {
  advanced: [{
deviceId: "64815-wi3c89-1839dk-x82-392aa"
    }, {
volume: 0.5
    }]
};

var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["aspectRatio"] || !supports["facingMode"]) {
  // Treat like an error.
}
var gotten = navigator.mediaDevices.getUserMedia({
  video: {
    width: {min: 320, ideal: 1280, max: 1920},
    height: {min: 240, ideal: 720, max: 1080},
    frameRate: 30,     // Shorthand for ideal.
    // facingMode: "environment" would be optional.
    facingMode: {exact: "environment"}
  }});

var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["width"] || !supports["height"]) {
  // Treat like an error.
}
var gotten = navigator.mediaDevices.getUserMedia({video: {
  width: {min: 640, ideal: 1280, max: 1920},
  height: {min: 480, ideal: 720, max: 1080},
}});

var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["width"] || !supports["height"] || !supports["facingMode"]) {
  // Treat like an error.
}
var gotten = navigator.mediaDevices.getUserMedia({video: {
  facingMode: {exact: "user"},
  width: {exact: 640},
  height: {exact: 480}
}});

dictionary DoubleRange {
    double max;
    double min;
};

dictionary ConstrainDoubleRange : DoubleRange {
    double exact;
    double ideal;
};

dictionary LongRange {
    long max;
    long min;
};

dictionary ConstrainLongRange : LongRange {
    long exact;
    long ideal;
};

dictionary ConstrainBooleanParameters {
    boolean exact;
    boolean ideal;
};

dictionary ConstrainDOMStringParameters {
    (DOMString or sequence<DOMString>) exact;
    (DOMString or sequence<DOMString>) ideal;
};

typedef (long or ConstrainLongRange) ConstrainLong;

typedef (double or ConstrainDoubleRange) ConstrainDouble;

typedef (boolean or ConstrainBooleanParameters) ConstrainBoolean;

typedef (DOMString or sequence<DOMString> or ConstrainDOMStringParameters) ConstrainDOMString;

{
  frameRate: {
    min: 1.0,
    max: 60.0
  },
  facingMode: [ "user", "left" ]
}

{
  width: {
    min: 640,
    max: 800
  },
  height: {
    min: 480,
    max: 600
  },
  aspectRatio: 1.3333333333
}

dictionary Capabilities {
};

{
  frameRate: 30.0,
  facingMode: "user"
}

dictionary Settings {
};

dictionary ConstraintSet {
};

dictionary Constraints : ConstraintSet {
    sequence<ConstraintSet> advanced;
};

12. Examples

<input type="button" value="Start" onclick="start()" id="startBtn">
<script>
 var startBtn = document.getElementById('startBtn');

 function start() {
     navigator.mediaDevices.getUserMedia({
   audio: true,
   video: true
     }).then(gotStream).catch(logError);
     startBtn.disabled = true;
 }

 function gotStream(stream) {
     stream.getTracks().forEach(function (track) {
   track.onended = function () {
       startBtn.disabled = stream.active;
   };
     });
 }

 function logError(error) {
     log(error.name + ": " + error.message);
 }
</script>

<article>
 <style scoped>
  video { transform: scaleX(-1); }
  p { text-align: center; }
 </style>
 <h1>Snapshot Kiosk</h1>
 <section id="splash">
  <p id="errorMessage">Loading...</p>
 </section>
 <section id="app" hidden>
  <p><video id="monitor" autoplay></video> <canvas id="photo"></canvas>
  <p><input type=button value="&#x1F4F7;" onclick="snapshot()">
 </section>
 <script>
 var video = document.getElementById('monitor');
 var canvas = document.getElementById('photo');

 navigator.mediaDevices.getUserMedia({
     video: true
 }).then(function (stream) {
     video.srcObject = stream;
     video.onloadedmetadata = function () {
         canvas.width = video.videoWidth;
         canvas.height = video.videoHeight;
         document.getElementById('splash').hidden = true;
         document.getElementById('app').hidden = false;
     };
 }).catch(function (reason) {
     document.getElementById('errorMessage').textContent = 'No camera available.';
 });

 function snapshot() {
     canvas.getContext('2d').drawImage(video, 0, 0);
 }
 </script>
</article>

13. Privacy Indicator Requirements

For each kind of device that getUserMedia() exposes,

• Define any<kind>Accessible (e.g. anyAudioAccessible, anyVideoAccessible) as the logical OR of the [[kindsAccessibleMap]][kind] value and all the [[devicesAccessibleMap]][deviceId] values for devices of that kind.
• Define any<kind>Live (e.g. anyAudioLive, anyVideoLive) to be the logical OR of the [[kindsLiveMap]] [kind] value and all the [[devicesLiveMap]] [deviceId] values for devices of that kind.

Define anyAccessible to be the logical OR of all any<kind>Accessible values.

Define anyLive to be the logical OR of all any<kind>Live values.

Then the following are requirements on the User Agent:

• The User Agent MUST indicate to the user when the value of anyAccessible changes.
• The User Agent MUST indicate to the user when the value of anyLive changes.
• If the User Agent provides indication to the user per kind, then for each any<kind>Accessible value and any<kind>Live value, it MUST at minimum indicate when the value changes.
• If the User Agent provides indication to the user per device, then for each [[devicesAccessibleMap]] [deviceId] value and [[devicesLiveMap]] [deviceId] value, it MUST at minimum indicate when the value changes.
• Any false-to-true transition indicated MUST remain observable for a sufficient time that a reasonably-observant user could become aware of it.
• Any of the above transition indications MAY be combined as long as the combined indication cannot transition to false if any of its component indications are still true.

and the following are encouraged behaviors for the User Agent:

• The User Agent is encouraged to provide ongoing indication of the current state of anyAccessible.
• The User Agent is encouraged to provide ongoing indication of the current state of anyLive and to make any generic hardware device indicator light match.
• If the User Agent provides indication to the user per kind, then for each any<kind>Accessible value and any<kind>Live value, it is encouraged to provide ongoing indication of the current state of the value. It is also encouraged to make any device-type-specific hardware indicator light match the corresponding any<kind>Live value.
• If the User Agent provides indication to the user per device, then for each [[devicesAccessibleMap]] [deviceId] value and [[devicesLiveMap]] [deviceId] value, it is encouraged to provide ongoing indication of the current state of the value. It is also encouraged to make any device-specific hardware indicator light match the corresponding [[devicesLiveMap]][deviceId] value.
• Any of the above ongoing indications MAY be used instead of the corresponding required transition indication provided the false-to-true transition requirement is met.

14. Privacy and Security Considerations

This section is non-normative; it specifies no new behavior, but instead summarizes information already present in other parts of the specification.

This document extends the Web platform with the ability to manage input devices for media - in this iteration, microphones, and cameras. It also allows the manipulation of audio output devices (speakers and headphones). Capturing audio and video exposes personally-identifiable information to applications, and this specification requires obtaining explicit user consent before sharing it.

Without authorization (to the "drive-by web"), it offers the ability to tell how many devices there are of each class, and how they are grouped together (e.g. a microphone and camera belonging to a single Web cam). The identifiers for the devices are designed to not be useful for a fingerprint that can track the user between origins, but the number and grouping of devices adds to the fingerprint surface. It recommends to treat the per-origin persistent identifier deviceId as other persistent storage (e.g. cookies) are treated.

When authorization is given, this document describes how to get access to, and use, media data from the devices mentioned. This data may be sensitive; advice is given that indicators should be supplied to indicate that devices are in use, but both the nature of authorization and the indicators of in-use devices are platform decisions.

Authorization may be given on a case-by-case basis, or be persistent. In the case of a case-by-case authorization, it is important that the user be able to say "no" in a way that prevents the UI from blocking user interaction until permission is given - either by offering a way to say a "persistent NO" or by not using a modal permissions dialog.

When authorization to any media device is given, application developers gain access to the labels of all available media capture devices. In most cases, the labels are persistent across browsing sessions and across origins that have also been granted authorization, and thus potentially provide a way to track a given device across time and origins.

For origins to which permission has been granted, the devicechange event will be emitted across browsing contexts and origins each time a new media device is added or removed; user agents can mitigate the risk of correlation of browsing activity across origins by fuzzing the timing of these events.

Once a developer gains access to a media stream from a capture device, the developer also gains access to detailed information about the device, including its range of operating capabilities (e.g. available resolutions for a camera). These operating capabilities are for the most part persistent across browsing sessions and origins, and thus provide a way to track a given device across time and origins.

Once access to a video stream from a capture device is obtained, that stream can most likely be used to fingerprint uniquely the said device (e.g. via dead pixel detection). Similarly, once access to an audio stream is obtained, that stream can most likely be used to fingerprint user location down to the level of a room or even simultaneous occupation of a room by disparate users (e.g. via analysis of ambient audio or of unique audio purposely played out of the device speaker). User-level mitigation for both audio and video consists of covering up the camera and/or microphone or revoking permission via browser chrome controls.

It is possible to use constraints so that the failure of a getUserMedia call will return information about devices on the system without prompting the user, which increases the surface available for fingerprinting. The User Agent should consider limiting the rate at which failed getUserMedia calls are allowed in order to limit this additional surface.

In the case of persistent authorization via a stored permission, it is important that it is easy to find the list of granted permissions and revoke permissions that the user wishes to revoke.

Once permission has been granted, the User Agent should make two things readily apparent to the user:

• That the page has access to the devices for which permission is given
• Whether or not any of the devices are presently recording ("on air") indicator

16. Change Log

This section will be removed before publication.

Changes since June 05, 2017

1. [#471] Add track to stream's track set only when constructor's argument is present

Changes since February 05, 2017

1. [#432] Ignore ideal values that don't belong on the device
2. [#433] Specify the "applyConstraints algorithm" more clearly
3. [#437] Specify that getSettings omits non-applicable settings
4. [#442] Add guidance for new MediaStream/MediaStreamTrack consumers
5. [#449] Remove outdated contraints text
6. [#445] Add autoGainControl and noiseSuppression constraints
7. [#456] Add text about alternative ways to obtain local media (e.g. for automatic testing)
8. [#450] MediaStream: allow construction with a given id

Changes between December 16, 2016 and February 5, 2017

1. [#395] Mark the Implementation Suggestions as non-normative.
2. [#422] Clarify where devicechange events fire.
3. [#424] Misc editorial
4. [#427] Update text on whether context object is allowed to request access.
5. [#430] Loosen getConstraints return value requirement
6. [#431] Require all constraints to be satisfied when settings are changed

Changes since November 23, 2016

1. [#420] Make removal of device(s) fire devicechange event
2. [#421] Add privacy indicator requirements

Changes since September 13, 2016

1. [#398] Editorial: Fix links to MediaStream's methods
2. [#399] Unroll steps in 'add a track' and 'remove a track'
3. [#401] Define states to be used in indicator requirements
4. [#410] Rename list-devices permission to device-info to match permission spec
5. [#412] Specify rules for when devicechange events may fire
6. [#415] Remove unions in MediaTrackCapabilities

Changes since June 24, 2016

1. [#376] Allow firing devicechange just once when inserting a camera with mic
2. [#378] Editorial: Update URLs in copyright to https
3. [#379] Device change events also occur during active media capture
4. [#381] Add pre-grant deviceId alternative
5. [#383] Editorial: Make constraints webidl optional in gUM call
6. [#392] Add room fingerprinting to security considerations

Changes since May 13, 2016

1. [#362] Replace "user media in an iFrame" section with use of new 'user media enabled flag'
2. [#365] Editorial: update content and format of images
3. [#367] Editorial: convert to WebIDL contiguous mode

Changes since April 23, 2016

1. [#348, #346] Removes sourceType from the document
2. [#349, #339] Use 'originIdentifier' in getUserMedia() steps
3. [#358, #352] Getusermedia: Pull the permissions check into the per-type loop
4. [#357, #354] Be specific on what live tracks grant implicit permission

Changes since April 6, 2016

1. [#333] Restrict devicechange event to apps with device-info permission
2. [#338] Make ended event a simple event
3. [#342] Remove obsolte error names table
4. [#343] Clarify language around stored permission and revocation
5. [#345] Issue 316: add links to constrainable properties

Changes since February 22, 2016

1. [#318] MediaStreamTrack.stop(): Address early return for non-locally sourced tracks
2. [#319] Add text that incorporates Permission API's definition of permission handling.
3. [#321] Remove track attributes "remote" and "readonly"
4. [#323] Remove unused images
5. [#324, #325] editorial fixes
6. [#329, #330] Clarify that, with permission, deviceID persists as with other storage such as cookies but that groupID never persists
7. [#331] Use NotAllowedError for permission failure in getUserMedia algorithm

Changes since December 23, 2015

1. [#301, #292] getSupportedConstraints(): Remove prose about dictionary member default values
2. [#306, #288] Explain WebIDL limitation for ConstrainablePattern
3. [#308] Clarify how the generic applyConstraints algorithm applies to MediaStreamTracks
4. [#309, #267] Specify permission model for nested browsing contexts
5. [#313, #268] Extend iframe with a new allowusermedia attribute
6. [#315, #307, #296] Clarify how Capabilites should work

Changes since December 8, 2015

1. [#286] Fix facingMode in MediaTrackCapabilities and example
2. [#289] Describe the echoCancellation capability
3. [#290] Use single double instead of same max and min for the aspectRadio capability in example
4. [#291] Remove MediaStream active/inactive events
5. [#284] Clarify that constraint in overconstrainederror is defined in selectSettings
6. [#297] Add new extension text

Changes since September 25, 2015

1. [#259] Specify that groupId is to be cleared when cookies are
2. [#261, #255] Warn against UUID fingerprinting
3. [#260] Update privacy section with lessons from TAG questionnaire
4. [#262] Mark sources of fingerprinting
5. [#258] Reorganize definition of constrainable properties without a registry
6. [#266] Add detailed steps for removeTrack() and fix a security considerations issue
7. [#272] Fix applyConstraints steps to avoid unused var and bail on reject
8. [#273] Add exception for stored permissions in text about stopped sources and revoked permissions
9. [#278, #250] PING: Refer to security-arch on the MUST inside Best Practice for HTTPS
10. [#280] Let removeTrack() reference the 'remove a track' steps
11. [#282] Clarify equality for string constraints
12. [#279, #193] Used frame rate for generic concept

Changes since August 26, 2015

1. [#226] Typedef MediaStreamError to be an object.
2. [#253] Clarify in section 5 that tracks don't request changes, but they can want different settings based on application use of applyConstraints.
3. [#239] Reject gUM promise with a TypeError if no media types are given.
4. [#240] Specify that groupid is origin-unique.
5. [#241] Reference WebIDL-1.
6. [#245] Make applyConstraints argument optional.
7. [#247] Clean up language in SelectSettings.

Changes since June 29, 2015

1. [#204] Use WebIDL [SameObject] extended attribute
2. [#209] Once you implement a MediaTrackSupportedConstraints member, you support it
3. [#215] MediaStreamErrorEvent -> OverconstrainedErrorEvent
4. [#214] Create new ErrorEvent
5. [#208] Add WebIDL definitions to Constrainable Pattern section to pass WebIDL validator
6. [#201, #207] Specify order of add/removetrack and active/inactive events
7. [#194, #162] New Overconstrainederror
8. [#213] Fix Not Found Error in gUM algorithm
9. [#181] Remove text about firing event handlers (from event handler attribute descriptions)

Changes since May 23, 2015

1. [LC-3016, #171] Referring to html5.1 for describing srcObject in media elements
2. [LC-3011, #196, #200] Replace 'invoke MediaDevices.getUserMedia()' with a reference to the algorithm
3. [LC-3017, #188] Changed SourceAvailableError to a NotReadableError DOMException
4. [LC-3017, #187] Changed PermissionDeniedError to a SecurityError DOMException
5. [LC-3017, #185] Changed NotSupportedError from a MediaStreamError to a DOMException
6. [LC-3017, #184] Changed AbortError from a MediaStreamError to a DOMException
7. [#180, #195] Replaced asynchronously with in parallel
8. [LC-3017, #186] Change NotFoundError from a MediaStreamError to a DOMException
9. [#174, #182] Tidy up getUserMedia() algorithm
10. [LC-3022, #177] Add latency constraint
11. [#178, #179] Add serializer to MediaDeviceInfo.
12. [LC-3025, #175] Add note about addtrack and removetrack not being used by this spec
13. [LC-3018, #163, #172] Use [Exposed]

Changes since April 10, 2015

1. [PR #156] Fix broken fragment
2. [Issue #164] Removed detach source from descriptions
3. [PR #166] Added steps describing the procedure to update a track's muted state.
4. [PR #167] Refer to internal algorithms for track adding and cloning instead of API layer methods
5. [PR #168] Remove setting the active state in MediaStream constructor
6. [PR #169] Use required dictionary track dictionary member on MediaStreamTrackEventInit
7. [Issue #180] Switch terminology from "asynchronously" to "in parallel" to follow the HTML standard

Changes since March 24, 2015

1. [PR #151] Remove outdated issues in the doc
2. [PR #152] using "browsing session" instead of "session"
3. [PR #153] short descriptions of arguments to callbacks in callback-based gUM

Changes since February 2, 2015

1. Added getUserMedia() implementation suggestion as discussed in issue #67
2. Issue 139: Clarified in SelectSettings algorithm that an empty constraint is to be treated as no constraint.
3. Issue 128: Clarified in SelectSettings that bare values mean exact in the advanced array and ideal otherwise.
4. [PR#37/Bug 26654] Webidl in Constrainable
5. [Issue #141] MediaDeviceInfo.label and .groupId should not be nullable
6. [PR #150] Update text for how constraint dictionaries get extended

Changes since October 27, 2014

1. Bug 26953: Added more detail to the definition of volume.
2. Clarified in section 4.1 that synchronization is only an intention because some tracks cannot be synchronized.
3. Introduced and made consistent use of the term 'constrainable property' everywhere we refer to a property which can have Capabilities, Constraints, and Settings.
4. Changed constraint definition text using concepts and some direct text from PR 61.
5. Bug 113 (old 25771): Explanation of constraints in GUM call. Rewrote algorithm with separate SelectSettings step, used both in GUM and in applyConstraints.

Changes since September 24, 2014

1. Bug 25809: Added note warning about abuse of call-me URLs.
2. Bug 26918: Added note on clearing deviceId when clearing cookies.
3. Bug 25777: Added example of capabilities when only two video sizes are available.
4. Bug 26654: Added ConstrainBoolean.
5. Bug 26810: All callback-based methods have been converted to use Promises, except for the version of getUserMedia() defined under NavigatorUserMedia.

Changes since September 9, 2014

1. Bug 22214: How long do permissions persist?
2. Define algorithm for processing non-required constraints.
3. Bug 24933: deviceId is not registered as constraints, so apps can't choose device based on the device enumeration
4. Bug 25609: MediaStreamErrorEvent is incomplete

Changes since August 17, 2014

1. Bug 25988: Need a list of MediaStreamError "name" values
2. Bug 26623: Use commonest spelling of "cancellation"
3. Bug 25767: Missing Ref to Image Capture spec
4. Bug 22271: Terminology section should not have conformance requirements

Changes since July 4, 2014

1. Bug 22251: Added new NotFoundError, AbortError, SourceUnavailable errors to gUM call.
2. Bug 25786: User Agent allowance of files to be substituted for any input device is now permitted but not listed as best practice, i.e., no longer specifically recommended.

Changes since June 19, 2014

1. Bug 22354: Added privacy and security section.
2. Bug 25784: "on air" indication is underspecified - separated "access granted" and "on air" indicators.
3. Bug 26192: add onoverconstrained to MediaStreamTrack
4. Bug 25776: add groupID to MediaTrackConstraintSet
5. Bug 25780: Clarify step 3 of MediaStream.clone
6. Bug 25804: Change 'remote' attribute definition
7. Bug 25650: In getUserMedia algorithm if user denies permission spec is wrongly redirecting to Constraint Failure.
8. Bug 25605: Definition of MediaStreamTrackEvent is not complete
9. Bug 25651: All the links in spec should redirect to specified contents without failure.
10. Bug 25725: getUserMedia constraints should be non-nullable
11. Bug 25763: does the ID really have to be exactly 36 char long?
12. Bug 24934: invalid definition for the "seekable" attribute when MediaStream is set to srcObject.
13. Removed MediaStreamTrack new state (sourceType none removed as a consequence) (as discussed in bug 25787).
14. Bug 25801: Remove getNativeSettings()

Changes since May 7, 2014

1. Clarified that skipping of optional/advanced ConstraintSets is only permitted if they cannot be satisfied, not merely because the User Agent wishes to.
2. Bug 25855: Clarification about conformance requirements phrased as algorithms
3. Bug 25803: Mark section entitled "The model: sources, sinks, constraints, and settings" as non-normative
4. Bug 24015: Add callback to indicate when available media devices change (introduced Navigator.mediaDevices)
5. Bug 25860: make sure we have a bug to have a getTracks that gives you all the tracks
6. Bug 25884: applied constraint syntax consensus as realized in June 9 WG email from Peter Thatcher.
7. Moved getSupportedConstraints() method to MediaDevices object.
8. Added stricter requirements on the getSupportedConstraints() return value.
9. Added issue note in Constrainable Pattern section that ideal is not yet defined.
10. Added issue note for applyConstraints that how multiple unorderedConstraints are to be satisfied together is not yet defined.
11. Added informative notes that WebIDL discards unknown required properties and that application authors need to use the getSupportedConstraints() method.
12. Cleaned up the MediaStream API intro section (mainly MediaStream behavior that have moved to MediaStreamTrack).
13. The concept of MediaStreamTrack with a detachable source is now used throughout the spec (removed language saying that a MST could be disassociated from its track).
14. Moved peerIdentity related text to WebRTC.

Changes since March 21, 2014

1. New webIDL for Constrainable and Constraints.
2. Bug 24931: changed MediaError to MediaStreamError.
3. Bug 23817: Redundant TOC headers 8.1 & 9.1
4. Bug 25230: readyState attribute must be inherited while cloning a MediaStreamTrack
5. Bug 25249: Source should be detached when a MediaStreamTrack stops for any reason other than stop
6. Updated Event Summary section to match the spec regarding MediaStreamTrack.stop() (as discussed in bug 25248)
7. Made the MediaStream() constructor behave like addTrack() WRT adding ended tracks (as discussed in bug 25250).
8. Bug 25262: MediaStream Constructor algorithm must also check for MediaStreamTracks "ended" state while initializing "active" state.
9. Bug 25276: Initialization for VideoTrack.selected attribute is missing while specifying steps for "Loading and Playing a MediaStream in a Media Element"
10. Changed syntax of constraints to use 'require' and 'advanced' and support non-required, non-advanced constraints.
11. Bug 25360: MediaStreamTrack should not be considered as ended just because remote peer stopped sending data.
12. Bug 25275: VideoTrackList.selectedIndex initialization conflicts with HTML5 spec, "if no track is selected".
13. Removed mentioning of MediaStream received from other peer (as discussed in bug 25361).
14. Bug 22263: Clarify synchronization of tracks in a MediaStream
15. Bug 25441: Overconstrained muted state should not link with MediaStreamTrack.readyState

Changes since February 18, 2014

1. Bug 24928: Remove MediaStream state check from addTrack() algorithm.
2. Bug 24930: Remove MediaStream state check from the removeTrack() algorithm.
3. Added native settings to tracks.
4. Removed videoMediaStreamTrack and audioMediaStreamTrack since they are no longer necessary.

Changes since December 25, 2013

1. Make optional constraints a list of ConstraintSets. Make ConstraintSet an object.
2. Remove noaccess, move peerIdentity
3. Add constraints for sampleRate, sampleSize, and echoCancellation.
4. Aligned text in remainder of document with Constrainable changes.
5. Removed statements that constraints are not applied to read-only sources

Changes since November 5, 2013

1. ACTION-25: Switch mediastream.inactive to mediastream.active.
2. ACTION-26: Rewrite stop to only detach the track's source.
3. Bug 22338: Arbitrary changing of tracks.
4. Bug 23125: Use double rather than float.
5. Bug 22712: VideoFacingMode enum needs an illustration.
6. Moved constraints into a separate Constrainable interface.
7. Created a separate section on error handling.

Changes since October 17, 2013

1. Bug 23263: Add output device enumeration to GetSources
2. Introduced the Constrainable interface.
3. Change consensus note on constraints in IANA section.
4. Removed createObjectURL.
5. Bug 22209: Should not use MUST requirements on values provided by the developer.

Changes since August 24, 2013

1. Bug 22269: Renamed getSourceInfos() to getSources() and made the result async.
2. Bug 22229: Editorial input
3. Bug 22243: Clarify readonly track
4. Bug 22259: Disabled mediastreamtrack and state of media element
5. Bug 22226: Remove check of same source from MediaStream constructor algorithm
6. Replaced ended with inactive for MediaStream (resolves bug 21618).
7. Bug 22264: MediaStream.ended set to true on creation
8. Bug 22272: Permission revocation via MediaStreamTrack.stop()
9. Bug 22248: Relationship between MediaStreamTrack and HTML5 VideoTrack/AudioTrack after MediaStream assignment
10. Bug 22247: Setting loop attribute on a media element reading from a MediaStream

Changes since July 4, 2013

1. Bug 21967: Added paragraph on MediaStreamTrack enabled state and updated cloning algorithm.
2. Bug 22210: Make getUserMedia() algorithm use all numbered items.
3. Bug 22250: Fixed accidentally overridden error.
4. Bug 22211: Added async error when no valid media type is requested.
5. Bug 22216: Made NavigatorUserMediaError extend DOMError.
6. Bug 22249: Throw on attempts to set currentTime on media elements playing MediaStream objects.
7. Bug 22246: Made media.buffered have length 0.
8. Bug 22692: Updated media element to use HAVE_NOTHING state before media arrives on the played MediaStream and HAVE_ENOUGH_DATA as soon as media arrives.

May 29, 2013

1. Bug 22252: fixed usage of MUST in MediaStream() constructor description.
2. Bug 22215: made MediaStream.ended readonly.
3. Bug 21967: clarified MediaStreamTrack.enabled state initial value.
4. Added aspectRatio constraint, capability, and state.
5. Updated usage of MediaStreams in media elements.

May 15, 2013

1. Added explanatory section for constraints, capabilities, and states.
2. Added VideoFacingModeEnum (including left and right options).
3. Added getSourceInfos() and SourceInfo dictionary.
4. Added isolated streams.

April 29, 2013

1. Removed remaining photo APIs and references (since we have a separate Image Capture Spec).

March 20, 2013

1. Added readonly and remote attributes to MediaStreamTrack
2. Removed getConstraint(), setConstraint(), appendConstraint(), and prependConstraint().
3. Added source states. Added states() method on tracks. Moved sourceType and sourceId to be states.
4. Added source capabilities. Added capabilities() method on tracks.
5. Added clarifying text about MediaStreamTrack lifecycle and mediaflow.
6. Made MediaStreamTrack cloning explicit.
7. Removed takePhoto() and friends from VideoStreamTrack (we have a separate Image Capture Spec).
8. Made getUserMedia() error callback mandatory.

December 12, 2012

1. Changed error code to be string instead of number.
2. Added core of settings proposal allowing for constraint changes after stream/track creation.

November 15 2012

1. Introduced new representation of tracks in a stream (removed MediaStreamTrackList).
2. Updated MediaStreamTrack.readyState to use an enum type (instad of unsigned short constants).
3. Renamed MediaStream.label to MediaStream.id (the definition needs some more work).

October 1 2012

1. Limited the track kind values to "audio" and "video" only (could previously be user defined as well).
2. Made MediaStream extend EventTarget.
3. Simplified the MediaStream constructor.

June 23 2012

1. Rename title to "Media Capture and Streams".
2. Update document to comply with HTML5.
3. Update image describing a MediaStream.
4. Add known issues and various other editorial changes.

June 22 2012

1. Update wording for constraints algorithm.

June 19 2012

1. Added "Media Streams as Media Elements section".

June 12 2012

1. Switch to respec v3.

June 5 2012

1. Added non-normative section "Implementation Suggestions".
2. Removed stray whitespace.

June 1 2012

1. Added media constraint algorithm.

Apr 23 2012

1. Remove MediaStreamRecorder.

Apr 20 2012

1. Add definitions of MediaStreams and related objects.

Dec 21 2011

1. Changed to make wanted media opt in (rather than opt out). Minor edits.

Nov 29 2011

1. Changed examples to use MediaStreamOptions objects rather than strings. Minor edits.

Nov 15 2011

1. Removed MediaStream stuff. Refers to webrtc 1.0 spec for that part instead.

Nov 9 2011

1. Created first version by copying the webrtc spec and ripping out stuff. Put it on github.