W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2011

Re: Choosing devices and fidelity: A proposal (sort of)

From: Cullen Jennings <fluffy@cisco.com>
Date: Mon, 18 Jul 2011 11:06:45 -0700
Cc: public-webrtc@w3.org
Message-Id: <25000220-89F0-40E7-8461-531F1D36BC1B@cisco.com>
To: Harald Alvestrand <harald@alvestrand.no>

On Jul 18, 2011, at 3:07 , Harald Alvestrand wrote:

> Changing subject while (hopefully) preserving threading....
> 
> What I seem to detect as a possibly emerging consensus is this:
> 
> - There are cases where the browser needs to make a choice
>  - Which of multiple cameras to use
>  - Which of multiple microphones to use
>  - Which of multiple quality settings (music  vs voice) to use on audio codecs
> 
> - There are situations where the browser can make the pick automatically. In those situations, the browser should do it.
> 
> - There are situations where the user needs to choose, but the Web application does not care (front/back camera in simple webapps, for instance). In those cases, interaction through the browser chrome is needed.
> 
> - There are situations where a choice has to be made, and the Web application wants to influence this choice. We think there are lots of subtleties here.
> 
> What about this approach?
> 
> - There is an API object (JSON object?) called "hints" that the Web app can send to the browser to influence these choices - probably a parameter to the calls that add or modify streams.
> - In version 1.0 of the spec, the content of this object is left undefined, possibly with some reserved semantics for "if you want to experiment, use this kind of name for your attribute".
> - We iterate once the rest of the spec is reasonably stable.
> 
> Does that make sense?


The idea of having an extensible way to do this in the future make sense but I see no reason not to define some of the semantics now. We have clear use cases and lots of experience with deployed systems that need to be able to influence this type of thing. If people don't design there code for some types of these from the beginning, it becomes much harder to add later. Note that a given browser could ignore all the hints, if it did not want to implement them. 

Our goal here should be to allow construction of interoperable systems. Not to define bags to cary vendor specified browser specific stuff that is not interoperable. 
Received on Monday, 18 July 2011 18:07:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 18 July 2011 18:07:17 GMT