W3C home > Mailing lists > Public > public-media-capture@w3.org > February 2013

Re: Combined synchronous gUM proposal proposal

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 5 Feb 2013 11:56:56 -0500
Message-ID: <CABkgnnXSbmZjNao1_H7+829T9TyLwJhxuUUx1OzS5QxaUy8XdA@mail.gmail.com>
To: "public-media-capture@w3.org" <public-media-capture@w3.org>
As requested in the meeting, this is how you request two video streams:

var video1 = new VideoStreamTrack(constraints1);
var video2 = new VideoStreamTrack(constraints2);
var stream = new MediaStream([video1, video2]);
navigator.getUserMedia(stream, successCb, errorCb);

Furthermore, you can implement the old/existing API with the following
monkey patch, and therefore I'm inclined to remove the option to pass
constraints...

var theRealGUM = navigator.getUserMedia;
navigator.getUserMedia = function(constraintsOrStream, success, error) {
  if (! constraintsOrStream instanceOf MediaStream) {
    var tracks = [];
    if (constraintsOrStream.audio) {
      tracks.push(new AudioStreamTrack(constraintsOrStream.audio));
    }
    if (constraintsOrStream.video) {
      tracks.push(new AudioStreamTrack(constraintsOrStream.video));
    }
    var stream = new MediaStream(tracks);
    theRealGUM(stream, success, error);
  } else {
    theRealGUM(constraintsOrStream, success, error);
  }
};

On 6 December 2012 12:36, Martin Thomson <martin.thomson@gmail.com> wrote:
> 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 Tuesday, 5 February 2013 16:57:23 UTC

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