Combined synchronous gUM proposal proposal

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
failure);
  }
  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
API.

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.

--Martin

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