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

On 06/07/2012 02:55 PM, Stefan Hakansson LK wrote:
> 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.
I'm actually not sure; I think "audio:true" means that an audio track 
should be present, but the current language of our spec doesn't describe 
what happens in the case where the candidateSet is empty and the 
constraint set is "true" only; we go to step 7.6 of section 3.1.1 and 
pick a track from an empty set .... not well defined.
>
>>
>> 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.

That may make a lot of sense.

Received on Thursday, 7 June 2012 13:30:34 UTC