W3C home > Mailing lists > Public > public-media-capture@w3.org > December 2012

Combined synchronous gUM proposal proposal

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 6 Dec 2012 09:36:38 -0800
Message-ID: <CABkgnnXMtGV36tgW_5Oi3qb+7kX+q_76WKY7XvwEM3T2kRySjA@mail.gmail.com>
To: "public-media-capture@w3.org" <public-media-capture@w3.org>
Option 3 required that users create MediaStreamTrack objects of
specific types using the new operator.

  var audio = new AudioStreamTrack(...);
  var video = new VideoStreamTrack(...);
  var stream = new MediaStream([audio, video]);
  navigator.getUserMedia(stream, successCb, errorCb);

EKR wants to ensure that users who aren't constrained by the sorts of
constraints that lead to the need for this synchronous option aren't
forced to go through the extra steps.

  navigator.getUserMedia({audio:true, video:true}, successCb, errorCb);

This is trivially possible with an overload/union type:

  partial interface navigator {
    void getUserMedia(GetUserMediaInput shape,
GetUserMediaSuccessCallback success, GetUserMediaFailureCallback
  typedef (MediaStreamConstraints or MediaStream) GetUserMediaInput;
  callback GetUserMediaSuccessCallback = void (MediaStream stream);
  callback GetUserMediaFailureCallback = void (GetUserMediaError error);
  interface GetUserMediaError : Error {
    // not sure what goes here in addition to the other stuff

The success callback includes the same stream you provided as input,
or a newly created one that is based on your input constraints.  Same

Constraints are attached to tracks in the /higher effort/ API using
MediaTrackConstraints, which is nicer and enables things like getting
multiple cameras.  MediaStreamConstraints becomes the low-road option
for getUserMedia.

I briefly considered having getUserMedia return the MediaStream that
it creates, which would enable the creation of a placeholder using the
existing API, which would get us option 1 as well, but that seemed a
little over the top.

Received on Thursday, 6 December 2012 17:37:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:13 UTC