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

On 06/07/2012 01:46 PM, 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

Makes sense to me.

>
> 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

Just to check that I understand the syntax: you could actually get a 
MediaStream with no audio track since it is not mandatory, is that right.

>
> 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.

As I said, makes sense. I also think we should consider having 
constraints indicating the app wants the front or rear facing camera. At 
least for now, a very large set of devices have one front and one rear 
camera, and hopefully there is a way for the browser to integrate with 
the operating system that allows it to pass on this info (and the right 
camera/track being delivered).

Of course the user has the final say, but the default selection by the 
browser could be the intended one.

>
>              Harald
>
>
>

Received on Thursday, 7 June 2012 12:56:24 UTC