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

RE: Grabbing exactly one camera (Re: Implementation suggestions)

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Wed, 1 Aug 2012 23:01:43 +0000
To: Dan Burnett <dburnett@voxeo.com>, Harald Alvestrand <harald@alvestrand.no>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B38383F3976@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
> From: Dan Burnett [mailto:dburnett@voxeo.com]
> 
> On Jun 7, 2012, at 7:46 AM, Harald Alvestrand wrote:
> 
> > On 06/07/2012 08:23 AM, Anant Narayanan wrote:
> > I'm starting to like Stefan's "let's grab'em all" approach for dealing with
> multiple cameras... what if we define some constraints?
> >
> > Video:<Min/Max>Tracks
> >
> > so that
> >
> > getUserMedia({video: {mandatory [{MinTracks: 2}]}, audio:true}}, ....)
> >
> > would give a MediaStream with at least 2 video tracks and at least one
> > audio track, while
> >
> > getUserMedia({video: {mandatory [{MaxTracks: 1}]}, audio:true}}, ....)
> >
> > would give a MediaStream guaranteed to have no more than one video
> > track (and give a hint to the UI for approval to make camera
> > selections exclusive)
> >
> > That would give us the expressive power without messing up the
> interfaces for the simple case.
> 
> Actually, I do not understand how this would work, since in your example
> there could be 2 or more video tracks, but the remaining video constraints
> would not distinguish which tracks they apply to.
> 
> I thought we had decided on only one track of each media type in each
> LocalMediaStream returned from getUserMedia().

Did we close on this point? I've been assuming at most one track "type" per [new] LocalMediaStream object, and if additional devices are wanted, then call getUserMedia again?
Received on Wednesday, 1 August 2012 23:02:15 UTC

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