- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Wed, 25 Jan 2012 08:50:04 +0100
- To: Randell Jesup <randell-ietf@jesup.org>
- CC: public-webrtc@w3.org
On 01/24/2012 09:59 PM, Randell Jesup wrote:
>> This led us to propose that 1) the return from getCapabilities()
>> should be a collection of profiles/configurations that the browser is
>> capable of providing, and that 2) the input to the Hints API should
>> be an author-ordered subset of these configurations. While it does
>> not guarantee in advance which configuration the author will get, it
>> does guarantee that if an acceptable configuration can be provided it
>> will be, without having to try, fail, try again, fail again, etc.
>
> A problem I see with this is a combinatorial problem: if
> getCapabilities returns the "collection of profiles/configurations the
> browser is capable of providing", then when you add multiple devices
> (multiple mics, multiple cameras, etc) the set of options becomes
> quite large, and selecting from it becomes more involved. I'm not
> saying impossible, but the added complexity for the typical
> application (and how likely they are to test it properly against
> possible capabilities) worries me a bit.
Possibly naive implementations will be written to the pattern of
getCapabilities({video=on, audio=on}, capsEventCallback)
capsEventCallback(caps) {
if (caps) {
getUserMedia(caps)
} else {
error("No permissions granted")
}
}
that is, the naive version is "just grab the first thing the user is
willing to grant me".
It's then up to UA implementation quality to actually return something
sensible in its first option.
Received on Wednesday, 25 January 2012 07:50:34 UTC