W3C home > Mailing lists > Public > public-media-capture@w3.org > September 2012

Re: Settings retrieval/application API Proposal (formerly: constraint modification API v3)

From: Randell Jesup <randell-ietf@jesup.org>
Date: Tue, 04 Sep 2012 01:13:27 -0400
Message-ID: <50458DF7.5070402@jesup.org>
To: public-media-capture@w3.org
On 9/3/2012 2:48 AM, Stefan Hakansson LK wrote:
> Travis,
> overall I like this a lot. It is very clear which objects you can use to
> change properties of the generated media ("MediaDevices"), which I think
> is a good thing.

This effectively causes a pointer to the source to follow along with 
tracks, providing a reasonable approximation of my proposal, in a 
simple-to-understand and use form.

The one issue that this doesn't address directly is competing settings - 
if you fork a track to two streams, and consumers use them to set 
different values for a parameter, you have to take the 
"last-setter-wins" approach.  This is a viable answer, but one that may 
cause pain for applications that don't want that answer.

  (I also know that constraints are being documented in a separate
> registry; I personally have no strong view on the right thing to do in
> this respect - to me it matters more that we sort out when and how they
> can be applied and that there is a way to add more data as experience
> shows the need).
> You do not discuss the relation between checking and setting properties
> of a MediaDevice using this proposal and the application of constraints
> (beyond "video") at getUserMedia time. To me it seems that they're
> complementary rather than conflicting: constraints at getUserMedia time
> helps the UA order (and perhaps prune) the list of available devices to
> the user in the dialog presented (if constraints are mandatory it could
> even lead to a failure without involving the user).

I'll add that all track sources that want to allow changes need to have 
MediaDevices.  For example, a PeerConnection output stream will need to 
create MediaDevice interfaces for each track, allowing requests for 
changes to be forwarded up to the JS application to deal with (or 
reject/ignore).  Ditto a track sourced at a <video> element.

Randell Jesup
Received on Tuesday, 4 September 2012 05:14:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:36 UTC