- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Sat, 4 Aug 2012 15:25:28 +0200
- To: public-media-capture@w3.org
On 08/02/2012 01:01 AM, Travis Leithead wrote:
>> 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?
If I remember correctly, the discussion ended in that each getUserMedia
call would only deliver max one track per type, but if you could call
getUserMedia several times before coming to a stable state, and those
calls would be combined into one user dialogue (allowing the app to ask
for several tracks of the same type with only one user consent request
coming up).
>
>
Received on Saturday, 4 August 2012 13:25:52 UTC