Re: constraints use case

On Fri, Mar 28, 2014 at 9:47 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>  Regarding a fallback scenario, there is:
>

> - Use a bluetooth microphone, if one is plugged in, otherwise fallback to
> the built-in microphone.
>

In Chrome this works, if you specify sourceId as optional.

>
> Going slightly off-topic, shouldn't we be able to do this as well?
>
> - Use a bluetooth microphone, but if/when it's unplugged, fallback to the
> built-in microphone. And vice-versa, if the bluetooth microphone is plugged
> in mid-call, switch over to it.
>

You'll need to use gUM to get the BT mic when it's plugged in, but yes,
that should work. (I don't think auto-switching is reasonable or expected.)

>
> Meaning, we should have to restart the call to switch devices.
>
> Gili
>
>
> On 28/03/2014 12:19 PM, Justin Uberti wrote:
>
> So far I have been asked about these real-world use cases on
> discuss-webrtc:
> - Choose between 720p and sub-HD (typically 480p or 360p) resolution
> (maxHeight, maxWidth).
> - Choose frame rate, especially for screen capture (maxFrameRate)
> - Control DSP settings (echoCancellation et al.)
>  - Choose camera (sourceId).
>
>  I am not aware of any scenarios that require complicated fallback
> semantics.
>
>
> On Thu, Mar 27, 2014 at 3:47 PM, Martin Thomson <martin.thomson@gmail.com>wrote:
>
>> Earlier today, I enjoyed Cullen's use of the slippery slope fallacy in
>> response to the request that a use case be produced to support the
>> current constraints expressiveness.
>>
>> Can anyone produce one?  We're not going to build a castle on this
>> foundation, but it might be interesting to know just how high we need
>> to pile our stones.  One probably isn't enough, but I can't recall
>> anything.
>>
>> A mailing list URL would suffice.
>>
>>
>
>