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

On Jun 7, 2012, at 9:29 AM, Harald Alvestrand wrote:

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

Hmm, I thought I had addressed this, but you are right that I mistakenly bypassed the error condition.  I had intended "audio:true" to mean Mandatory.  I will have to tweak the algorithm to fix this.

>> 
>>> 
>>> 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 15:04:55 UTC