Initial Author of this Specification was Ian Hickson, Google Inc., with the following copyright statement:
 © Copyright 2004-2011 Apple Computer, Inc., Mozilla Foundation, and Opera Software ASA. You are granted a license to use, reproduce and create derivative works of this document.
All subsequent changes since 26 July 2011 done by the W3C WebRTC Working Group and the Device APIs Working Group are under the following Copyright:
© 2011-2013 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. Document use  rules apply.
For the entire publication on the W3C site the liability and trademark rules apply.
This document defines a set of JavaScript APIs that allow local media, including audio and video, to be requested from a platform.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is not complete. It is subject to major changes and, while early experimentations are encouraged, it is therefore not intended for implementation. The API is based on preliminary work done in the WHATWG.
This document was published by the Web Real-Time Communication Working Group and Device APIs Working Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to public-media-capture@w3.org (subscribe, archives). All comments are welcome.
Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures (Web Real-Time Communication Working Group, Device APIs Working Group) made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This section is non-normative.
Access to multimedia streams (video, audio, or both) from local devices (video cameras, microphones, Web cams) can have a number of uses, such as real-time communication, recording, and surveillance.
This document defines the APIs used to get access to local devices that can generate multimedia stream data. This document also defines the MediaStream API by which JavaScript is able to manipulate the stream data or otherwise process it.
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 MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification 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.
Implementations that use ECMAScript 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], as this specification uses that specification and terminology.
The EventHandler
        interface represents a callback used for event handlers as defined in
        [HTML5].
The concepts queue a task and fires a simple event are defined in [HTML5].
The terms event handlers and event handler event types are defined in [HTML5].
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.
Some sources have an identifier which must be unique to the application (un-guessable by another application) and persistent between application sessions (e.g., the identifier for a given source device/application must stay the same, but not be guessable by another application). Sources that must have an identifier are camera and microphone sources; local file sources are not required to have an identifier. Source identifiers let the application save, identify the availability of, and directly request specific sources.
Other than the identifier, other bits of source identity are never directly available to the application until the user agent connects a source to a track. Once a source has been "released" to the application (either via a permissions UI, pre-configured allow-list, or some other release mechanism) the application will be able discover additional source-specific capabilities.
Sources do not have constraints -- tracks have constraints. When a source is connected to a track, it must, possibly in combination with UA processing (e.g., downsampling), conform to the constraints present on that track (or set of tracks).
Sources will be released (un-attached) from a track when the track is ended for any reason.
On the MediaStreamTracksourceType attribute. The behavior
        of APIs associated with the source's capabilities and settings change
        depending on the source type.
Sources have capabilities and
        settings. The capabilities and settings 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).
A setting refers to the immediate, current value of the source's (optionally constrained) capabilities. 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 mandatory constraints that all of the tracks it is bound to have defined, and should do its best to conform to the set of optional constraints specified.
Although settings are a property of the source, they are
        only exposed to the application through the tracks attached to
        the source.  The Constrainable interface provides this
        exposure.
A conforming user-agent must support all the setting names defined in this spec.
Source capabilities are the intrinsic "features" of a
        source object.  For each source setting, there is a
        corresponding capability that describes whether it is
        supported by the source and if so, what the range of supported
        values are. As with settings, capabilities are exposed to the
        application via the Constrainable 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 session.
Constraints
      Constraints are an optional track feature for restricting the range of allowed variability on a source. Without provided track constraints, implementations are free to select a source's settings from the full ranges of its supported capabilities, and to adjust those settings at any time for any reason.
Constraints are exposed on tracks via
        the Constrainable interface, which includes an API for
        dynamically changing constraints.  Note
        that getUserMedia() also permits an initial set of
        constraints to be applied when the track is first
        obtained.
It is possible for two tracks that share a unique source to
        apply contradictory constraints. The Constrainable
        interface supports the calling of an error handler when the
        conflicting constraint is requested.  After successful
        application of constraints on a track (and its associated
        source), if at any later time the track
        becomes overconstrained, the user agent MUST change the
        track to the muted state.
A correspondingly-named constraint exists for each corresponding source setting name and capability name. 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.
RTCPeerConnection
      RTCPeerConnection is defined in
      [WEBRTC10].The MediaStreamMediaStream
Each MediaStream
Each track in a MediaStream object has a corresponding
      MediaStreamTrack
A MediaStreamTrack
A channel is the smallest unit considered in this API specification.
A MediaStreamMediaStreamgetUserMedia() call (which is
      described later in this document), for instance, might take its input
      from the user's local camera. The output of the object controls how the
      object is used, e.g., what is saved if the object is written to a file or
      what is displayed if the object is used in a video
      element.
Each track in a MediaStream
A MediaStream
The output of a MediaStream
A new MediaStreamMediaStream() constructor. The constructor
      argument can either be an existing MediaStreamMediaStreamMediaStreamTrack
 
      
Both MediaStreamMediaStreamTrackMediaStream
When a MediaStreamMediaStream object is also used in contexts outside
      getUserMedia, such as [WEBRTC10]. In both cases, ensuring
      a realtime stream reduces the ease with which pages can distinguish live
      video from pre-recorded video, which can help protect the user's
      privacy.
The MediaStream()
      constructor composes a new stream out of existing tracks. It takes an
      optional argument of type MediaStreamMediaStreamTrack
Let stream be a newly constructed
          MediaStream
Initialize stream's id attribute to a newly generated
          value.
If the constructor's argument is present, run the sub steps that corresponds to the argument type.
Array of MediaStreamTrack
Run the following sub steps for each
              MediaStreamTrack
Add track: Let track be the
                  MediaStreamTrack
If track has ended, then abort these steps and continue with the next track (if any).
Add track to stream's track set.
Run the sub steps labeled Add track (above) for every
              MediaStreamTrack
If stream's track set is
          empty, set stream's active attribute to
          false, otherwise set it to true.
Return stream.
A MediaStreamMediaStream
The tracks of a MediaStreamMediaStreamTrackMediaStreamTrackid.
An object that reads data from the output of a
      MediaStreamMediaStreamMediaStreamRTCPeerConnection [WEBRTC10],
      MediaRecorder [mediastream-rec] and
      ImageCapture [mediastream-imagecap].
MediaStream
A MediaStreamMediaStream
When a MediaStreamactive attribute to
      false and fire a simple event named inactive at the object. When a
      MediaStreamactive attribute to
      true and fire a simple event named active at the object.
If the stream's activity status changed due to a user request, the task source for this task is the user interaction task source. Otherwise the task source for this task is the networking task source.
[ Constructor,
 Constructor (MediaStream stream),
 Constructor (sequence<MediaStreamTrack> tracks)]
interface MediaStream : EventTarget {
    readonly    attribute DOMString    id;
    sequence<MediaStreamTrack> getAudioTracks ();
    sequence<MediaStreamTrack> getVideoTracks ();
    MediaStreamTrack?          getTrackById (DOMString trackId);
    void                       addTrack (MediaStreamTrack track);
    void                       removeTrack (MediaStreamTrack track);
    MediaStream                clone ();
    readonly    attribute boolean      active;
                attribute EventHandler onactive;
                attribute EventHandler oninactive;
                attribute EventHandler onaddtrack;
                attribute EventHandler onremovetrack;
};MediaStreamMediaStream| Parameter | Type | Nullable | Optional | Description | 
|---|---|---|---|---|
| stream |  | ✘ | ✘ | 
MediaStream| Parameter | Type | Nullable | Optional | Description | 
|---|---|---|---|---|
| tracks | sequence< | ✘ | ✘ | 
active of type boolean, readonly   The MediaStream.active
          attribute returns true if the MediaStream
When a MediaStreamactive attribute
          MUST be set to true, unless stated otherwise (for example by the
          MediaStream() constructor
          algorithm).
id of type DOMString, readonly   When a MediaStreamid attribute to that string. Such
          strings MUST only use characters in the ranges U+0021, U+0023 to
          U+0027, U+002A to U+002B, U+002D to U+002E, U+0030 to U+0039, U+0041
          to U+005A, U+005E to U+007E, and MUST be 36 characters long.
The id attribute
          MUST return the value to which it was initialized when the object was
          created.
onactive of type EventHandler,            active, MUST be supported by all
        objects implementing the MediaStreamonaddtrack of type EventHandler,            addtrack, MUST be supported by
        all objects implementing the MediaStreamoninactive of type EventHandler,            inactive, MUST be supported by
        all objects implementing the MediaStreamonremovetrack of type EventHandler,            removetrack, MUST be
        supported by all objects implementing the
        MediaStreamaddTrackAdds the given MediaStreamTrackMediaStream
When the addTrack() method is
          invoked, the user agent MUST run the following steps:
Let track be the
              MediaStreamTrackMediaStream
If stream is finished, throw an
              INVALID_STATE_ERR exception.
If track is already in stream's track set, then abort these steps.
Add track to stream's track set.
| Parameter | Type | Nullable | Optional | Description | 
|---|---|---|---|---|
| track |  | ✘ | ✘ | 
voidcloneClones the given MediaStream
When the MediaStream.clone() method
          is invoked, the user agent MUST run the following steps:
Let streamClone be a newly constructed
              MediaStream
Initialize streamClone's id attribute to a newly
              generated value.
Let trackSetClone be a list that contains the
              result of running MediaStreamTrack.clone()
              on all the tracks in this stream.
Let trackSetClone be streamClone's track set.
MediaStreamgetAudioTracksReturns a sequence of MediaStreamTrack
The getAudioTracks()
          method MUST return a sequence that represents a snapshot of all the
          MediaStreamTrackkind is equal to
          "audio". The conversion from the track set to the sequence is user agent defined and
          the order does not have to stable between calls.
sequence<MediaStreamTrack>getTrackByIdThe getTrackById()
          method MUST return the first MediaStreamTrackid is equal to
          trackId. The method MUST return null if no track matches
          the trackId argument.
| Parameter | Type | Nullable | Optional | Description | 
|---|---|---|---|---|
| trackId | DOMString | ✘ | ✘ | 
MediaStreamTrackgetVideoTracksReturns a sequence of MediaStreamTrack
The getVideoTracks()
          method MUST return a sequence that represents a snapshot of all the
          MediaStreamTrackkind is equal to
          "video". The conversion from the track set to the sequence is user agent defined and
          the order does not have to stable between calls.
sequence<MediaStreamTrack>removeTrackRemoves the given MediaStreamTrackMediaStream
When the removeTrack() method
          is invoked, the user agent MUST run the following steps:
Let track be the
              MediaStreamTrackMediaStream
If stream is finished, throw an
              INVALID_STATE_ERR exception.
If track is in stream's track set, remove it.
| Parameter | Type | Nullable | Optional | Description | 
|---|---|---|---|---|
| track |  | ✘ | ✘ | 
voidA MediaStreamTrackMediaStreamTrackgetUserMedia()
      .
A script can indicate that a track no longer needs its source with the
      MediaStreamTrack.stop() method.
      When all tracks using a source have been stopped, the given permission
      for that source is revoked and the source is stopped. If the data is being generated from a
      live source (e.g., a microphone or camera), then the user agent SHOULD
      remove any active "on-air" indicator for that source. If the data is
      being generated from a prerecorded source (e.g. a video file), any
      remaining content in the file is ignored. An implementation may use a per
      source reference count to keep track of source usage, but the specifics
      are out of scope for this specification.
A MediaStreamTracknew, live and ended.
        A track begins as new prior to being connected to an
        active source.
Once connected, the started event fires and
        the track becomes live. In the live state,
        the track is active and media is available for rendering at a
        MediaStream
A muted or disabled MediaStreamTrackMediaStreamTrackMediaStream
The muted/unmuted state of a track reflects if the source provides
        any media at this moment. The enabled/disabled state is under
        application control and determines if the track outputs media (to its
        consumers). Hence, media from the source only flows when a
        MediaStreamTrack
A MediaStreamTrackMediaStreamRTCPeerConnection [WEBRTC10], is muted if the
        application on the other side disables the corresponding track in the
        MediaStream being sent.
Applications are able to enable or
        disable a MediaStreamTrack
For a newly created MediaStreamTrack
A MediaStreamTrack
When a MediaStreamTrackstop() method being invoked on
        the MediaStreamTrack
If the track's readyState attribute
            has the value ended already, then abort these steps.
            (The stop()
            method was probably called just before the track stopped for other
            reasons.)
Set track's readyState attribute
            to ended.
Fire a simple event named ended at the object.
If the end of the stream was reached due to a user request, the event source for this event is the user interaction event source.
Constraints are set on a per-track basis rather than on the
        source itself. However, if the
        sourceType is "none" or the
        remote attribute is true, the track's
        constraints will not be applied to the source.
Whether ConstraintsConstrainable Interface allow the retrieval
        and manipulation of the constraints currently established on a
        track.
Each track maintains an internal version of the
        Constraintsconstraints attribute, and may be modified by the
        applyConstraints() method.
When applyConstraints() is called, a user agent
        MUST queue a task to evaluate
        those changes when the task queue is next serviced. Similarly, if the
        sourceType
        changes, then the user agent MUST perform the same actions to
        re-evaluate the constraints of each track affected by that source
        change.
If the MediaError
MediaStreamTrack implements Constrainable;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 boolean               _readonly;
    readonly    attribute boolean               remote;
    readonly    attribute MediaStreamTrackState readyState;
                attribute EventHandler          onstarted;
                attribute EventHandler          onended;
    MediaStreamTrack clone ();
    void             stop ();
};enabled of type boolean,            The MediaStreamTrack.enabled
            attribute, on getting, MUST return the last value to which it was
            set. On setting, it MUST be set to the new value, and then, if the
            MediaStreamTrack
Thus, after a MediaStreamTrackenabled attribute still
            changes value when set; it just doesn't do anything with that new
            value.
id of type DOMString, readonly   Unless a MediaStreamTrackid attribute to
            that string.
An example of an algorithm that specifies how the track id must
            be initialized is the algorithm to represent an incoming network
            component with a MediaStreamTrack
MediaStreamTrack.id
            attribute MUST return the value to which it was initialized when
            the object was created.
kind of type DOMString, readonly   The MediaStreamTrack.kind
            attribute MUST return the string "audio" if the object
            represents an audio track or "video" if object
            represents a video track.
label of type DOMString, readonly   User agents MAY label audio and video sources (e.g., "Internal
            microphone" or "External USB Webcam"). The MediaStreamTrack.label
            attribute MUST return the label of the object's corresponding
            track, if any. If the corresponding track has or had no label, the
            attribute MUST instead return the empty string.
Thus the kind and label attributes do not
            change value, even if the MediaStreamTrack
muted of type boolean, readonly   The MediaStreamTrack.muted
            attribute MUST return true if the track is muted, and false otherwise.
onended of type EventHandler,            ended, MUST be supported
          by all objects implementing the MediaStreamTrackonmute of type EventHandler,            mute, MUST be supported by
          all objects implementing the MediaStreamTrackonstarted of type EventHandler,            started, MUST be
          supported by all objects implementing the
          MediaStreamTrackonunmute of type EventHandler,            unmute, MUST be supported
          by all objects implementing the MediaStreamTrackreadonly of type boolean, readonly   readonly attribute
          MUST return the value true. Otherwise, it must return
          the value false.readyState of type MediaStreamTrackState, readonly   The readyState
            attribute represents the state of the track. It MUST return the
            value to which the user agent last set it.
remote of type boolean, readonly   RTCPeerConnection, the
          remote
          attribute MUST return the value true. Otherwise, it must
          return the value false.cloneClones the given MediaStreamTrack
When the MediaStreamTrack.clone()
            method is invoked, the user agent MUST run the following steps:
Let trackClone be a newly constructed
                MediaStreamTrack
Initialize trackClone's id attribute to a newly
                generated value.
Let trackClone inherit this track's underlying
                source, kind, label and
                enabled
                attributes, as well as its currently active constraints.
Return trackClone.
MediaStreamTrackstopWhen a MediaStreamTrackstop() method is
            invoked, the user agent MUST run following steps:
Let track be the current
                MediaStreamTrack
If track has no source attached
                (sourceType is "none") or if the source is
                provided by an RTCPeerConnection, then abort these
                steps.
Set track's readyState
                attribute to ended.
Detach track's source.
If no other MediaStreamTrack
The task source for the tasks
            queued for the stop() method is the DOM
            manipulation task source.
voidenum MediaStreamTrackState {
    "new",
    "live",
    "ended"
};| Enumeration description | |
|---|---|
| new | The track type is new and has not been initialized (connected to a source of any kind). This state implies that the track's label will be the empty string. | 
| live | The track is active (the track's underlying media source is making a best-effort attempt to provide data in real time). The output of a track in the  | 
| ended | The track has ended (the track's underlying media source is no longer providing data, and will never provide more data for this track). Once a track enters this state, it never exits it. For example, a video track in a  | 
enum SourceTypeEnum {
    "none",
    "camera",
    "microphone"
};| Enumeration description | |
|---|---|
| none | This track has no source. This is the case when the track is in
          the "new"or"ended"readyState. | 
| camera | A valid source type only for s. The source is a local
          video-producing camera source. | 
| microphone | A valid source type only for s. The source is a local
          audio-producing microphone source. | 
When the peerIdentity option is supplied to
        getUserMedia, the resulting
        MediaStreamMediaStream
Displayed in an appropriate tag (e.g., a video or audio element). The browser MUST ensure that content is inaccessible to the application by ensuring that the resulting content is given the same protections as content that is CORS cross-origin, as described in the relevant Security and privacy considerations section of [HTML5].
Used as the argument to addStream() for an RTCPeerConnection, subject to the restrictions detailed in [WEBRTC10].
A MediaStreamTrackMediaStreamMediaStreamMediaStreamMediaStreamTrack
Any peerIdentity property MUST be retained
        on cloned
        copies of MediaStreamTrack
The addtrack
      and removetrack events use the
      MediaStreamTrackEvent
Firing a track event named
      e with a MediaStreamTrackMediaStreamTrackEventtrack
      attribute set to track, MUST be created and dispatched at the
      given target.
dictionary MediaStreamTrackEventInit : EventInit {
    MediaStreamTrack? track;
};
[ Constructor (DOMString type, MediaStreamTrackEventInit eventInitDict)]
interface MediaStreamTrackEvent : Event {
    readonly    attribute MediaStreamTrack track;
};MediaStreamTrackEventTODO
| Parameter | Type | Nullable | Optional | Description | 
|---|---|---|---|---|
| type | DOMString | ✘ | ✘ | |
| eventInitDict |  | ✘ | ✘ | 
track of type MediaStreamTrack, readonly   The track attribute
          represents the MediaStreamTrack
MediaStreamTrackEventInit Memberstrack of type MediaStreamTrack, nullableTODO
The MediaStreamTrackMediaStreamTrack
Note that the camera's green light
 doesn't come on when a new
      track is created; nor does the user get prompted to enable the
      camera/microphone. Those actions only happen after the developer has
      requested that a media stream containing "new" tracks be
      bound to a source via getUserMedia(). Until that
      point tracks are inert.
Video tracks may be instantiated with optional media track constraints. These constraints can be later modified on the track as needed by the application, or created after-the-fact if the initial constraints are unknown to the application.
Example: VideoStreamTrack
new VideoStreamTrack();
new VideoStreamTrack({ "optional": [{ sourceId: "20983-20o198-109283-098-09812" }, { width: { min: 800, max: 1200 } }, { height: { min: 600 } }] });
[ Constructor (optional Constraints videoConstraints)]
interface VideoStreamTrack : MediaStreamTrack {
};VideoStreamTrackTODO
| Parameter | Type | Nullable | Optional | Description | 
|---|---|---|---|---|
| videoConstraints |  | ✘ | ✔ | 
Example: AudioStreamTrack
new AudioStreamTrack();
new AudioStreamTrack({ optional: [{ sourceId: "64815-wi3c89-1839dk-x82-392aa" }, { gain: 0.5 }] });
[ Constructor (optional Constraints audioConstraints)]
interface AudioStreamTrack : MediaStreamTrack {
};AudioStreamTrack| Parameter | Type | Nullable | Optional | Description | 
|---|---|---|---|---|
| audioConstraints |  | ✘ | ✔ | 
Browsers provide a media pipeline from sources to sinks. In a browser, sinks are the <img>, <video> and <audio> tags. Traditional sources include streamed content, files, and web resources. The media produced by these sources typically does not change over time - these sources can be considered to be static.
The sinks that display these sources to the user (the actual tags
    themselves) have a variety of controls for manipulating the source content.
    For example, an <img> tag scales down a huge source image of
    1600x1200 pixels to fit in a rectangle defined with
    width="400" and height="300".
The getUserMedia API adds dynamic sources such as microphones and cameras - the characteristics of these sources can change in response to application needs. These sources can be considered to be dynamic in nature. A <video> element that displays media from a dynamic source can either perform scaling or it can feed back information along the media pipeline and have the source produce content more suitable for display.
Note: This sort of feedback loop is obviously just enabling an "optimization", but it's a non-trivial gain. This optimization can save battery, allow for less network congestion, etc...
Note that MediaStream sinks (such as
    <video>, <audio>, and even
    RTCPeerConnection) will continue to have mechanisms to further
    transform the source stream beyond that which the Settings,
    Capabilities, and Constraints described in this specification
    offer. (The sink transformation options, including those of
    RTCPeerConnection, are outside the scope of this
    specification.)
The act of changing or applying a track constraint may affect the
    settings of all tracks sharing that source and
    consequently all down-level sinks that are using that source. Many sinks
    may be able to take these changes in stride, such as the
    <video> element or RTCPeerConnection.
    Others like the Recorder API may fail as a result of a source setting
    change.
The RTCPeerConnection is an interesting object because it
    acts simultaneously as both a sink and a source for
    over-the-network streams. As a sink, it has source transformational
    capabilities (e.g., lowering bit-rates, scaling-up or down resolutions,
    adjusting frame-rates), and as a source it could have its own states
    changed by a track source (though in this specification sources with the
    remote attribute set to true do not consider the
    current constraints applied to a track).
To illustrate how changes to a given source impact various
    sinks, consider the following example. This example only uses
    width and height, but the same principles apply to any of
    the Settings exposed in this specification. In the first
    figure a home client has obtained a video source from its local
    video camera. The source's width and height settings are 800 pixels
    by 600 pixels, respectively. Three MediaStreamsourceId. The three media streams are connected to
    three different sinks: a <video> element (A), another
    <video> element (B), and a peer connection (C). The peer
    connection is streaming the source video to an away client. On the away
    client there are two media streams with tracks that use the peer connection
    as a source. These two media streams are connected to two
    <video> element sinks (Y and Z).
 
    Note that at this moment, all of the sinks on the home client must apply a transformation to the original source's provided dimension settings. A is scaling the video up (resulting in loss of quality), B is scaling the video down, and C is also scaling the video up slightly for sending over the network. On the away client, sink Y is scaling the video way down, while sink Z is not applying any scaling.
Using the Constrainable interface, one of the tracks
    requests a higher resolution (1920 by 1200 pixels) from the home
    client's video source.
 
    Note that the source change immediately affects all of the tracks and sinks on the home client, but does not impact any of the sinks (or sources) on the away client. With the increase in the home client source video's dimensions, sink A no longer has to perform any scaling, while sink B must scale down even further than before. Sink C (the peer connection) must now scale down the video in order to keep the transmission constant to the away client.
While not shown, an equally valid settings change request could be made of the away client video source (the peer connection on the away client's side). This would not only impact sink Y and Z in the same manner as before, but could lead to re-negotiation with the peer connection on the home client in order to alter the transformation that it is applying to the home client's video source. Such a change is NOT REQUIRED to change anything related to sink A or B or the home client's video source.
Note that this specification does not define a mechanism by which a change to the away client's video source could automatically trigger a change to the home client's video source. Implementations may choose to make such source-to-sink optimizations as long as they only do so within the constraints established by the application, as the next example demonstrates.
It is fairly obvious that changes to a given source will impact sink
    consumers. However, in some situations changes to a given sink may also be
    cause for implementations to adjust a source's settings.
    This is illustrated in the following figures. In the first figure
    below, the home client's video source is sending a video stream sized at
    1920 by 1200 pixels. The video source is also unconstrained, such that the
    exact source dimensions are flexible as far as the application is
    concerned. Two MediaStreamsourceId, and those
    MediaStream<video> element sinks A and B. Sink A has been sized to
    width="1920" and height="1200" and is displaying
    the source's video content without any transformations. Sink B has been
    sized smaller and, as a result, is scaling the video down to fit its
    rectangle of 320 pixels across by 200 pixels down.
 
    When the application changes sink A to a smaller dimension (from 1920 to 1024 pixels wide and from 1200 to 768 pixels tall), the browser's media pipeline may recognize that none of its sinks require the higher source resolution, and needless work is being done both on the part of the source and on sink A. In such a case and without any other constraints forcing the source to continue producing the higher resolution video, the media pipeline MAY change the source resolution:
 
    In the above figure, the home client's video source resolution was changed to the greater of that from sinkA and from sinkB in order to optimize playback. While not shown above, the same behavior could apply to peer connections and other sinks.
It is possible that constraints can be applied to a
    track which a source is unable to satisfy, either because the
    source itself cannot satisfy the constraint or because the source
    is already satisfying a conflicting constraint. When this happens,
    the applyConstraints() call will fail and call the
    user-provided ConstraintErrorCallback, without applying any
    of the new constraints.  Since no change in constraints occurs in
    this case, there is also no required change to the source itself
    as a result of this condition. Here is an example of this
    behavior.
In this example, two media streams each have a video track that share the same source. The first track initially has no constraints applied. It is connected to sink N. Sink N has a width and height of 800 by 600 pixels and is scaling down the source's resolution of 1024 by 768 to fit. The other track has a mandatory constraint forcing off the source's fill light; it is connected to sink P. Sink P has a width and height equal to that of the source.
 
    
Now, the first track adds a mandatory constraint that the fill light should be forced on. At this point, both mandatory constraints cannot be satisfied by the source (the fill light cannot be simultaneously on and off at the same time). Since this state was caused by the first track's attempt to apply a conflicting constraint, the constraint application fails and there is no change in the source's settings or the constraints on either track.
Let's look at a slightly different situation starting from the same point. In this case, instead of the first track attempting to apply a conflicting constraint, the user physically locks the camera into a mode where the fill light is on. At this point the source can no longer satisfy the second track's mandatory constraint that the fill light be off. The second track is transitioned into the muted state and receives an overconstrained event. At the same time, the source notes that its remaining active sink only requires a resolution of 800 by 600 and so it adjusts its resolution down to match (this is an optional optimization that the user agent is allowed to make given the situation).
 
    
At this point, it is the responsibility of the application to address the problem that led to the overconstrained situation, perhaps by removing the fill light mandatory constraint on the second track or by closing the second track altogether and informing the user
A MediaStream may be assigned to media elements as defined
    in HTML5
    [HTML5] 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 MediaStream is paused.
UAs that support this specification MUST support the following partial interface, which allows a MediaStream to be assigned directly to a media element.
partial interface HTMLMediaElement {
                attribute MediaStream? srcObject;
};srcObject of type MediaStream,            , nullableHolds the MediaStream that provides media for this element. This
          attribute overrides both the src attribute and any
          <source> elements. Specifically, if srcObject is
          specified, the UA MUST use it as the source of media, even if the
          src attribute is also set or <source> children are
          present. If the value of srcObject is replaced or set to
          null the UA MUST re-run the 
          media element load algorithm
We may want to allow direct assignment of other types as well
The UA runs the 
      media element load algorithm to obtain media for the media element to
      display. As defined in the [HTML5] specification, this algorithm has
      two basic phases: 
      resource selection algorithm chooses the resource to play and
      resolves its URI. Then the 
      resource fetch phase loads the resource. Both these phases are
      potentially simplified when using a MediaStream. First of all,
      srcObject takes priority over other means of specifying the
      resource, and it provides the object itself rather than a URI. Therefore,
      there is no need to run the resource selection algorithm. Secondly, when
      the UA reaches the resource fetch algorithm with a MediaStream, the
      MediaStream is a local object so there's nothing to fetch. Therefore, the
      following modifications/restrictions to the 
      media element load algorithm apply:
Whenever the user agent runs the 
          media element load algorithm, if srcObject is
          specified, the UA must immediately go to the 
          resource fetch phase of the algorithm.
Whenever the user agent runs the 
          media element load algorithm, reaches the 
          resource fetch phase of this algorithm, and determines that the
          media resource in question is a MediaStream, it MUST immediately
          abort the 
          resource selection algorithm, setting the 
          media.readyState to HAVE_NOTHING if media is not yet
          available and to HAVE_ENOUGH_DATA once it is.
For each MediaStreamTrackMediaStreamAudioTrack
          or VideoTrack
          as defined in [HTML5]. Since the order in the
          MediaStreamAudioTrackList
          and VideoTrackList
          are ordered.
The properties of the AudioTrack and
          VideoTrack objects MUST be initialized as follows.
          Let
AudioTrack.id and VideoTrack.id have
              the value of the corresponding MediaStreamTrack.id
              attribute
AudioTrack.kind and VideoTrack.kind
              be "main"
AudioTrack.label and
              VideoTrack.label have the value of the corresponding
              MediaStreamTrack.label
              attribute
AudioTrack.language and
              VideoTrack.language be the empty string
AudioTrack.enabled be true
Set the 
          VideoTrackList.selectedIndex to the index of the first
          VideoTrack, in the VideoTrackList, that
          corresponds to a MediaStreamTrackVideoTrack
          exists, set the selectedIndex attribute to 0.
(Note that since the MediaStream is potentially endless, the UA does not exit the media element load algorithm until the MediaStream moves from the active to the inactive state.)
If a MediaStreamTrackMediaStreamAudioTrack or VideoTrack MUST
          be removed as well.
The UA MUST NOT buffer data from a MediaStream. When playing, the UA MUST always play the current data from the stream.
When the MediaStream is moves from the active to the inactive state, the UA MUST raise an 
          ended event on the media element and set its ended
          attribute to true. Note that once ended
          equals true the media element will not play media even
          if new Tracks are added to the MediaStream (causing it to return to
          the active state) unless autoplay is true
          or the JavaScript restarts the element, e.g., by calling play().
The nature of the MediaStream places certain restrictions
      on the behavior and attribute values of the associated media element and
      on the operations that can be performed on it, as shown below:
| Attribute Name | Attribute Type | Valid Values When Using a MediaStream | Additional considerations | 
|---|---|---|---|
| currentSrc | DOMString | the empty string | When srcObjectis specified the UA MUST set this
            to the empty string. | 
| preload | DOMString | none | A MediaStream cannot be preloaded. | 
| buffered | TimeRanges | buffered.lengthMUST return0. | A MediaStream cannot be preloaded. Therefore, the amount buffered is always an empty TimeRange. | 
| networkState | unsigned short | NETWORK_IDLE | The media element does not fetch the MediaStream so there is no network traffic. | 
| readyState | unsigned short | HAVE_NOTHING, HAVE_ENOUGH_DATA | A may be created before there
            is any data available, for example when a stream is received from a
            remote peer. The value of thereadyStateof the media
            element MUST be HAVE_NOTHING before the first media arrives and
            HAVE_ENOUGH_DATA once the first media has arrived. | 
| currentTime | double | Any positive integer. The initial value is 0 and the values increments linearly in real time whenever the stream is playing. | The value is the current stream position, in seconds. On any
            attempt to set this attribute, the user agent must throw an InvalidStateErrorexception. | 
| duration | unrestricted double | Infinity | A MediaStream does not have a pre-defined duration. | 
| seeking | boolean | false | A MediaStream is not seekable. Therefore, this attribute MUST
            always have the value false. | 
| defaultPlaybackRate | double | 1.0 | A MediaStream is not seekable. Therefore, this attribute MUST
            always have the value 1.0and any attempt to alter it
            MUST fail. | 
| playbackRate | double | 1.0 | A MediaStream is not seekable. Therefore, this attribute MUST
            always have the value 1.0and any attempt to alter it
            MUST fail. | 
| played | TimeRanges | played.lengthMUST return1.played.start(0)MUST return0.played.end(0)MUST return the last knowncurrentTime. | A MediaStream's timeline always consists of a single range, starting at 0 and extending up to the currentTime. | 
| seekable | TimeRanges | seekable.lengthMUST return0.seekable.start()MUST returncurrentTime.seekable.end()MUST returncurrentTime. | A MediaStream is not seekable. | 
| startDate | Date | Not-a-Number (NaN) | A MediaStream does not specify a timeline offset. | 
| loop | boolean | true, false | Setting the loopattribute has no effect since ahas no defined end and therefore
            cannot be looped. | 
All errors defined in this specification implement the following interface:
[NoInterfaceObject]
interface MediaError {
    readonly    attribute DOMString  name;
    readonly    attribute DOMString? message;
    readonly    attribute DOMString? constraintName;
};constraintName of type DOMString, readonly   , nullableThis attribute is only used for some types of errors. For
        MediaErrorConstraintNotSatisfiedError, this attribute MUST be set to
        the name of the constraint that caused the error.
message of type DOMString, readonly   , nullablename of type DOMString, readonly   The name of the error
The following interface is defined for cases when a MediaError is raised as an event:
dictionary MediaErrorEventInit : EventInit {
    MediaError error;
};
[ Constructor (DOMString type, MediaErrorEventInit eventInitDict)]
interface MediaErrorEvent : Event {
    readonly    attribute MediaError error;
};MediaErrorEvent| Parameter | Type | Nullable | Optional | Description | 
|---|---|---|---|---|
| type | DOMString | ✘ | ✘ | |
| eventInitDict |  | ✘ | ✘ | 
error of type MediaError, readonly   MediaErrorEventInit Memberserror of type MediaErrorTODO
This section is non-normative.
The following event fires on MediaStream
| Event name | Interface | Fired when... | 
|---|---|---|
| active | Event | The became active (see inactive). | 
| inactive | Event | The became inactive. | 
| addtrack |  | A new has been added to this
          stream. Note that this event is not fired when the script directly
          modifies the tracks of a. | 
| removetrack |  | A has been removed from this
          stream. Note that this event is not fired when the script directly
          modifies the tracks of a. | 
The following event fires on MediaStreamTrack
| Event name | Interface | Fired when... | 
|---|---|---|
| started | Event | The object has just
          transitioned from the "new"readyStateto another
          state. This event fires before any other corresponding events such as
          "ended" or "statechanged". | 
| mute | Event | The object's source is
          temporarily unable to provide data. | 
| unmute | Event | The object's source is live
          again after having been temporarily unable to provide data. | 
| overconstrained | MediaErrorEvent | This error event fires asynchronously for each affected track
            (when multiple tracks share the same source) after the user agent
            has evaluated the current constraints against a given
             Due to being over-constrained, the user agent must mute each affected track. The affected track(s) will remain un-usable (in the
             | 
| ended | Event | The object's source will no
          longer provide any data, either because the user revoked the
          permissions, or because the source device has been ejected, or
          because the remote peer stopped sending data, or because thestop()method was invoked. | 
This section describes an API that the script can use to query the user agent about connected media input and output devices.
callback MediaDeviceInfoCallback = void (sequence<MediaDeviceInfo> deviceInfoList);MediaDeviceInfoCallback ParametersdeviceInfoList of type sequence<MediaDeviceInfo>MediaDeviceInfoNavigator.getMediaDevices()
        .dictionary MediaDeviceInfo {
    DOMString       deviceId;
    MediaDeviceKind kind;
    DOMString       label;
    DOMString       groupId;
};MediaDeviceInfo MembersdeviceId of type DOMStringThe unique id for the represented device.
groupId of type DOMStringReturns the group identifier of the represented device. Two devices has the same group identifier if they belong to the same physical device; for example a headset.
kind of type MediaDeviceKindDescribes the kind of the represented device.
label of type DOMStringA label describing this device (for example "External USB Webcam"). If the device has no associated label, then this dictionary member MUST return the empty string.
enum MediaDeviceKind {
    "audioinput",
    "audiooutput",
    "videoinput"
};| Enumeration description | |
|---|---|
| audioinput | Represents an audio input device; for example a microphone. | 
| audiooutput | Represents an audio output device; for example a pair of headphones. | 
| videoinput | Represents a video input device; for example a webcam. | 
The MediaStreamConstraints dictionary is used to instruct
      the UA what sort of MediaStreamTracks to include in the
      MediaStream returned by getUserMedia().
dictionary MediaStreamConstraints {
    (boolean or Constraints) video = false;
    (boolean or Constraints) audio = false;
    DOMString                peerIdentity;
};MediaStreamConstraints Membersaudio of type (boolean or Constraints), defaulting to falseIf true, it requests that the returned
          MediaStream contain an audio track. If a Constraints
          structure is provided, it further specifies the nature and settings
          of the audio Track. If false, the MediaStream
          MUST not contain an audio Track.
peerIdentity of type DOMStringIf the peerIdentity attribute is provided, the
          resulting MediaStream will be isolated from the application.
video of type (boolean or Constraints), defaulting to falseIf true, it requests that the returned
          MediaStream contain a video track. If a Constraints
          structure is provided, it further specifies the nature and settings
          of the video Track. If false, the MediaStream
          MUST not contain a video Track.
This section is non-normative.
The user agent is encouraged to reserve resources when it has determined that a given call to getUserMedia() will succeed. It is preferable to reserve the resource prior to invoking the success callback provided by the web page. Subsequent calls to getUserMedia() (in this page or any other) should treat the resource that was previously allocated, as well as resources held by other applications, as busy. Resources marked as busy should not be provided as sources to the current web page, unless specified by the user. Optionally, the user agent may choose to provide a stream sourced from a busy source but only to a page whose origin matches the owner of the original stream that is keeping the source busy.
This document recommends that in the permission grant dialog or device selection interace (if one is present), the user be allowed to select any available hardware as a source for the stream requested by the page (provided the resource is able to fulfill mandatory constraints, if any were specified), in addition to the ability to substitute a video or audio source with local files and other media. A file picker may be used to provide this functionality to the user.
This document also recommends that the user be shown all resources that are currently busy as a result of prior calls to getUserMedia() (in this page or any other page that is still alive) and be allowed to terminate that stream and utilize the resource for the current page instead. If possible in the current operating environment, it is also suggested that resources currently held by other applications be presented and treated in the same manner. If the user chooses this option, the track corresponding to the resource that was provided to the page whose stream was affected must be removed.
A MediaStream may contain more than one
        video and audio track. This makes it possible to include video from two
        or more webcams in a single stream object, for example. However, the
        current API does not allow a page to express a need for multiple video
        streams from independent sources.
It is recommended for multiple calls to getUserMedia() from the same page be allowed as a way for pages to request multiple, discrete, video or audio streams.
A single call to getUserMedia() will always return a stream with either zero or one audio tracks, and either zero or one video tracks. If a script calls getUserMedia() multiple times before reaching a stable state, this document advises the UI designer that the permission dialogs should be merged, so that the user can give permission for the use of multiple cameras and/or media sources in one dialog interaction. The constraints on each getUserMedia call can be used to decide which stream gets which media sources.
The Constrainable interface allows its consumers to inspect and adjust
    the properties of the object that implements it. It is broken out as a
    separate interface so that it can be used in other specifications. The core
    concept is that of a Capability, which consists of a property or feature 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 object's set of Capabilities via
    the getCapabilities() accessor.
The application can select the (range of) values it wants for an
    object's Capabilities by means of one or more 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 of them. 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). ConstraintSets can be mandatory or optional. In the
    case of optional ConstraintSets, the UA will consider the ConstraintSets in
    the order in which they are specified, and will try to satisfy each one,
    but will ignore a ConstraintSet if it cannot satisfy it. In the case of a
    mandatory ConstraintSet, the UA will try to satisfy it, and will call the
    errorCallback if it cannot do so. For example, suppose that an
    application applies three individual constraints, one stating that the
    video aspect ratio should be 3 to 2 (height to width), the next that the
    height should be 600 and the last that the width should be 500. Since these
    constraints interact with each other (the aspect ratio affects the possible
    values for height and width, and vice-versa) it is impossible to satisfy
    all three of them, so if they are all contained in a mandatory
    ConstraintSet, the UA will call the errorCallback. However if
    any one of the constraints is placed in an optional ConstraintSet, the
    other two can be satisfied, so the UA will satisfy the two mandatory ones,
    silently ignore the optional one, and call the
    successCallback.
The ordering of optional ConstraintSets is significant. In the example
    in the previous paragraph, suppose that aspect ratio constraint is part of
    a mandatory ConstraintSet and that the height and width constraints are
    part of separate optional ConstraintSets. If the height ConstraintSet is
    specified first (and the other constraints in the ConstraintSet can also be
    satisfied), then it will be satisfied and the width ConstraintSet will be
    ignored. Thus the height will be set to 600 and the the width will be set
    to 400. On the other hand, if width is specified before height, the width
    ConstraintSet will be satisfied and the height ConstraintSet will be
    ignored, resulting in width of 500 and height of 750. (Note that the
    mandatory aspect ratio constraint is enforced in both cases.) The UA will
    attempt to satisfy as many optional ConstraintSets as it can, even if some
    of them cannot be satisfied and must therefore be ignored. Application
    authors can therefore implement a backoff strategy by specifying multiple
    optional ConstraintSets for the same property. For example, an application
    might specify three optional ConstraintSets, the first asking for a
    framerate greater than 500, the second asking for a framerate greater than
    400, and the third asking for one greater than 300. If the UA is capable of
    setting a framerate greater than 500, it will (and the subsequent two
    ConstraintSets will be trivially satisfied.) However, if the UA cannot set
    the framerate above 500, it will ignore that ConstraintSet and attempt to
    set the framerate above 400. If that fails, it will then try to set it
    above 300. If the UA cannot satisfy any of the three ConstraintSets, it
    will set the framerate to any value it can get. If the developer wanted to
    insist on 300 as a lower bound, he put that in a mandatory ConstraintSet.
    In that case, the UA 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. An application may inspect the set of ConstraintSets currently in
    effect via the getConstraints() accessor.
The specific value that the UA chooses for a Capability 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 Capabilities via the getSettings()
    accessor.
[NoInterfaceObject]
interface Constrainable {
    Capabilities getCapabilities ();
    Constraints  getConstraints ();
    Settings     getSettings ();
    void         applyConstraints (Constraints constraints, VoidFunction successCallback, ConstraintErrorCallback errorCallback);
                attribute EventHandler onoverconstrained;
};onoverconstrained of type EventHandler,            overconstrained,
        must be supported by all objects
        implementing the ConstrainableThe UA must raise a
          MediaErrorEvent named "overconstrained" if changing
          circumstances at runtime result in it no longer
          being able to satisfy the currently valid mandatory
          ConstraintSet. This MediaErrorEvent
          must contain a MediaError whose
          name is "overconstrainedError", and whose
          constraintName attribute is set to one of the mandatory
          constraints that can no longer be satisfied. The message
          attribute of the MediaError SHOULD contain a string that is useful
          for debugging. The conditions under which this error might occur are
          platform and application-specific. For example, the user might
          physically manipulate a camera in a way that makes it impossible to
          provide a resolution that satisfies the constraints. The UA MAY take
          other actions as a result of the overconstrained situation.
applyConstraintsThe applyConstraints() algorithm for applying constraints is stated below. Here are some preliminary definitions that are used in the statement of the algorithm:
When applyConstraints is called, the UA must queue a task to run the following
          steps:
errorCallback, passing it a new
            MediaError with name
            ConstraintNotSatisfied and constraintName
            set to any of the mandatory constraints that could not be
            satisfied, and return. existingConstraints remain in
            effect in this case.successCallback. From this point on until applyConstraints() is
            called successfully again, getConstraints() must return the newConstraints that 
            	were passed as an argument
            to this call. The UA may choose new settings for the Capabilities of the object at any time. When it does so it must attempt to satisfy first the mandatory ConstraintSet and then the optional ConstraintSets in the order in which they were specified, as described in the algorithm above.
| Parameter | Type | Nullable | Optional | Description | 
|---|---|---|---|---|
| constraints |  | ✘ | ✘ | A new constraint structure to apply to this object. | 
| successCallback | VoidFunction | ✘ | ✘ | Called if the mandatory ConstraintSet can be satisfied. | 
| errorCallback |  | ✘ | ✘ | Called if the mandatory ConstraintSet cannot be satisfied. | 
voidgetCapabilitiesThe getCapabilities() method returns the dictionary of the capabilities that the object supports.
It is possible that the underlying hardware may not exactly map
            to the range defined in the registry entry. Where this is possible,
            the entry should define how
            to translate and scale the hardware's setting onto the values
            defined in the entry. For example, suppose that a registry entry
            defines a hypothetical fluxCapacitance capability that is defined
            to be the range from -10 (min) to 10 (max), but there are common
            hardware devices that support only values of "off" "medium" and
            "full". The registry entry might specify that for such hardware,
            the user agent should map the range value of -10 to "off", 10 to
            "full", and 0 to "medium". It might also indicate that given a
            ConstraintSet imposing a strict value of 3, the user agent should
            attempt to set the value of "medium" on the hardware, and and that
            getSettings() should return a fluxCapacitance
            of 0, since that is the value defined as corresponding to
            "medium".
CapabilitiesgetConstraintsapplyConstraints(), maintaining
          the order in which they were specified.  
        Note that some of
          the optional ConstraintSets returned may not be currently satisfied.
          To check which ConstraintSets are currently in effect, the application
        should use getSettings.
        ConstraintsgetSettingsapplyConstraints(). Note that the actual
        setting of a property must be a
        single value. 
Settingscallback ConstraintErrorCallback = void (MediaError error);ConstraintErrorCallback Parameterserror of type MediaErrorMediaError holding the mandatory constraint
              that could not be satisfied.An example of Constraints that could be passed into
      applyConstraints() or returned as a value of
      constraints is below. It uses the properties defined
      in the Track property registry.
{ "mandatory": { "width": { "min": 640 }, "height": { "min": 480 } }, "optional": [{ "width": 650 }, { "width": { "min": 650 } }, { "frameRate": 60 }, { "width": { "max": 800 } }, { "facingMode": "user" }] }
There is a single IANA registry that defines the constrainable properties of all objects that implement Constrainable. The registry entries must contain the name of each property along with its set of legal values. The registry entries for MediaStreamTrack are defined below. The syntax for the specification of the set of legal values depends on the type of the values. In addition to the standard atomic types (boolean, long, double, DOMString), legal values include lists of any of the atomic types, plus min-max ranges, as defined below.
List values must be interpreted
      as disjunctions. For example, if a property 'facingMode' for a camera is
      defined as having legal values ["left", "right", "user", "environment"],
      this means that 'facingMode' can have the value "left", the value
      "right", the value "environment" or the value "user". Similarly
      Constraints restricting 'facingMode' to ["user", "left", "right"]
      would mean that the UA should select a camera (or point the camera, if
      that is possible) so that "facingMode" is either "user", "left", or
      "right". This Constraint would thus request that the camera not be facing
      away from the user, but would allow the UA to choose among the other
      directions.
typedef PropertyValueSet DOMString[];dictionary PropertyValueDoubleRange {
    double max;
    double min;
};PropertyValueDoubleRange Membersmax of type doublemin of type doubledictionary PropertyValueLongRange {
    long max;
    long min;
};PropertyValueLongRange Membersmax of type longmin of type longCapabilities are dictionary containing one or more
      key-value pairs, where each key must be a constrainable property defined in the 
      registry, and each value must be
      a subset of the set of values defined for that property in the registry.
      The exact syntax of the value expression depends on the type of the
      property but is of type ConstraintValues
An example of a Capabilities dictionary is shown below. This example is not very realistic in that a browser would actually be required to support more settings that just these.
{ "frameRate": { "min": 1.0, "max": 60.0 }, "facingMode": ["user", "environment"] }
A Setting is a dictionary containing one or more key-value
      pairs. It must contain each key
      returned in getCapabilities(). There must be a single value for each key and the value
      must a member of the set defined
      for that property by capabilities(). The exact syntax of the
      value expression depends on the type of the property. It will be a
      DomString for properties of type PropertyValueSet, it will be a long for
      properties of type PropertyValueLongRange , it will be a double for
      properties of type PropertyValueDoubleRange. Thus the
      Settings dictionary contains the actual values that the UA
      has chosen for the object's Capabilities.
An example of a Setting dictionary is shown below. This example is not very realistic in that a browser would actually be required to support more settings that just these.
{ "frameRate": 30.0, "facingMode": "user" }
dictionary Constraints {
    ConstraintSet           mandatory;
    sequence<ConstraintSet> optional;
};Constraints Membersmandatory of type ConstraintSetThe set of constraints that the UA must satisfy or else call the
          errorCallback.
optional of type sequence<ConstraintSet>The list of ConstraintSets that the UA should try to satisfy but may ignore if they cannot be satisfied. The order of
          these ConstraintSets is significant. In particular, when they are
          passed as an argument to applyConstraints, the UA
          must try to satisfy them in the
          order that is specified. Thus if optional ConstraintSets C1 and C2
          can be satisfied individually, but not together, then whichever of C1
          and C2 is first in this list will be satisfied, and the other will
          not. The UA must attempt to
          satisfy all optional ConstraintSets in the list, even if some cannot
          be satisfied. Thus, in the preceding example, if optional constraint
          C3 is specified after C1 and C2, the UA will attempt to satisfy C3
          even though C2 cannot be satisfied. Note that a given property name
          may occur multiple times in these sets.
Each property of a ConstraintSet corresponds to a Capability and specifies a subset of its legal values. Applying a ConstraintSet instructs that UA to restrict the setting of the corresponding Capabilities to the specified values or ranges of values. A given property MAY occur both in the mandatory and the optional ConstraintSets list, and MAY occur more than once in the optional ConstraintSets list.
typedef (DOMString or long or double or boolean) ConstraintValue;typedef (ConstraintValue or PropertyValueSet or PropertyValueLongRange or PropertyValueDoubleRange) ConstraintValues;typedef object ConstraintSet;In ECMAScript, ConstraintSet objects are represented using regular native objects with optional properties whose names represent constraint name. The conversion from an ECMAScript value, representing a ConstraintSet, to an IDL ConstraintSet must not fail if a property name in the ECMAScript value does not match any of the Capabilities of the Constrainable object.
In ECMAScript, all the properties of the ConstraintSet object are
        optional; the developer may specify any of these properties when
        creating the object. Note, however, that unknown property names will
        result in a ConstraintSet that can not be satisfied, as described in
        applyConstraints() above.
This sample code exposes a button. When clicked, the button is disabled and the user is prompted to offer a stream. The user can cause the button to be re-enabled by providing a stream (e.g., giving the page access to the local camera) and then disabling the stream (e.g., revoking that access).
<input type="button" value="Start" onclick="start()" id="startBtn"> <script> var startBtn = document.getElementById('startBtn'); function start() { navigator.getUserMedia({ audio: true, video: true }, gotStream, logError); startBtn.disabled = true; } function gotStream(stream) { stream.oninactive = function () { startBtn.disabled = false; }; } function logError(error) { log(error.name + ": " + error.message); } </script>
This example allows people to take photos of themselves from the local video camera. Note that the forthcoming Image Capture specification may provide a simpler way to accomplish this.
<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="📷" onclick="snapshot()"> </section> <script> navigator.getUserMedia({ video: true }, gotStream, noStream); var video = document.getElementById('monitor'); var canvas = document.getElementById('photo'); function gotStream(stream) { video.srcObject = stream; stream.oninactive = noStream; video.onloadedmetadata = function () { canvas.width = video.videoWidth; canvas.height = video.videoHeight; document.getElementById('splash').hidden = true; document.getElementById('app').hidden = false; }; } function noStream() { document.getElementById('errorMessage').textContent = 'No camera available.'; } function snapshot() { canvas.getContext('2d').drawImage(video, 0, 0); } </script> </article>
This specification defines the following new error names
IANA is requested to register the following properties as specified in [RTCWEB-CONSTRAINTS]:
The following constraint names are defined to apply to both
      VideoStreamTrackAudioStreamTrack
| Property Name | Values | Notes | 
|---|---|---|
| sourceType | SourceTypeEnum | the type of the source of the MediaStreamTrack. | 
| sourceId | DOMString | The application-unique identifier for this source. The same identifier MUST be valid between sessions of this application, but MUST also be different for other applications. Some sort of GUID is recommended for the identifier. | 
The following properties are defined to apply only to
      VideoStreamTrack
| Property Name | Values | Notes | 
|---|---|---|
| width | PropertyValueLongRange | The width or width range, in pixels, of the video source. As a capability, the range should span the video source's pre-set width values with min being the smallest width and max being the largest width. | 
| height | PropertyValueLongRange | The height or height range, in pixels, of the video source. As a capability, the range should span the video source's pre-set height values with min being the smallest height and max being the largest height. | 
| frameRate | PropertyValueDoubleRange | The exact desired frame rate (frames per second) or frameRate range of the video source. If the source does not natively provide a frameRate, or the frameRate cannot be determined from the source stream, then this value MUST refer to the user agent's vsync display rate. | 
| aspectRatio | PropertyValueDoubleRange | The exact aspect ratio (width in pixels divided by height in pixels), represented as a double rounded to the tenth decimal place. | 
| facingMode | PropertyValueSet | The members of the enum describe the directions that the camera
            can face, as seen from the user's perspective. Valid values for the
            strings in the PropertyValueSet are the values of enum
            VideoFacingModeEnum. | 
enum VideoFacingModeEnum {
    "user",
    "environment",
    "left",
    "right"
};| Enumeration description | |
|---|---|
| user | The source is facing toward the user (a self-view camera). | 
| environment | The source is facing away from the user (viewing the environment). | 
| left | The source is facing to the left of the user. | 
| right | The source is facing to the right of the user. | 
Below is an illustration of the video facing modes in relation to the
      user.
      
The following properties are defined to apply only to
      AudioStreamTrack
| Property Name | Values | Notes | 
|---|---|---|
| volume | PropertyValueDoubleRange | The volume or volume range of the audio source, as a percentage. A volume of 0.0 is silence, while a volume of 1.0 is the maximum supported volume. Note that any ConstraintSet that specifies values outside of this range can never be satisfied. | 
| sampleRate | PropertyValueLongRange | The sample rate in samples per second for the audio data. | 
| sampleSize | PropertyValueLongRange | The linear sample size in bits. This constraint can only be satisfied for audio devices that produce linear samples. | 
| echoCancelation | boolean | When one or more audio streams is being played in the proceses of varios microphones, it is often desirable to attempt to remove the sound being played from the input signals recorded by the microphones. This is referred to echo cancelation. There are cases where it is not needed and it is desirable to turn it off so that no audio artifacts are introduced. This allows applications to control this behavior. | 
This section will be removed before publication.
The editors wish to thank the Working Group chairs and Team Contact, Harald Alvestrand, Stefan Håkansson and Dominique Hazaël-Massieux, for their support. Substantial text in this specification was provided by many people including Jim Barnett, Harald Alvestrand, Travis Leithead, and Stefan Håkansson.