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

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

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 4 Sep 2012 08:03:11 +0200
Message-ID: <5045999F.7040905@ericsson.com>
To: public-media-capture@w3.org
On 09/04/2012 07:13 AM, Randell Jesup wrote:
> 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.

As I understand it, it is up to the application to decide. It could 
apply "last-setter-wins", but just as well "highest(-resolution, 
framerate)-wins" or any other approach.

>    (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.

I agree, other sources that allow changes (such as PeerConnection) would 
need a similar API.

Received on Tuesday, 4 September 2012 06:03:39 UTC

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