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

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

From: Dan Burnett <dburnett@voxeo.com>
Date: Thu, 7 Jun 2012 11:05:57 -0400
Cc: public-media-capture@w3.org
Message-Id: <C83AB5F9-752A-49CF-A8F0-870145A53DF8@voxeo.com>
To: Harald Alvestrand <harald@alvestrand.no>

On Jun 7, 2012, at 7:46 AM, Harald Alvestrand wrote:

> On 06/07/2012 08:23 AM, Anant Narayanan wrote:
>> Hi Stefan,
>> 
>> On 06/05/2012 11:45 PM, Stefan Hakansson LK wrote:
>> 
>>> * Should there a way for the application to indicate that it wants only
>>> one audio and one video track when calling getUserMedia? If this was
>>> possible, the browser could then make the selections "exclusive-or" when
>>> set, "and" when not set.
>> 
>> I think there should be a normative way for non-trusted applications to specify a limited set of constraints to do this kind of thing. Let's discuss some proposals and see if we can reach some consensus.
> 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().


> 
>           Harald
> 
> 
> 
Received on Thursday, 7 June 2012 15:16:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:35 UTC