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

Re: Constraints and Capabilities API for getUserMedia: more detailed proposal

From: Anant Narayanan <anant@mozilla.com>
Date: Tue, 13 Mar 2012 10:36:42 -0700
Message-Id: <A6F30F1C-F804-409F-B9F8-6E6CE38B69CB@mozilla.com>
To: public-media-capture@w3.org
Hi Dan,

Thanks for taking the time to write this up!

On Mar 13, 2012, at 9:42 AM, Dan Burnett wrote:
> In step 3d the decision of which stream to choose from the CandidateSet is completely up to the browser.  Unless and until a new set of constraints is provided, the browser MAY change its choice of stream at any point, provided that it notifies the application code by again calling the successCallback with the resulting new FinalSet.  It may wish to do this, for example, if the user interface or network congestion changes.

I'm not sure I understand correctly, but does this mean the successCallback passed to getUserMedia can be called multiple times? If that is the case, I suspect the application will also need to know the difference between the first time it got a stream vs. when a stream it already has was changed. I think this notification is better suited to be an event on the MediaStream object itself, or a separate callback.

Also, what happens when the UA was able to satisfy the mandatory constraints at the time getUserMedia was invoked, but needs to change it later, when the MediaStream is actually put to use? Is the errorCallback then invoked?

As an example: getUserMedia isn't just called on the side that's making an outgoing video call, but also on the receiving side. I could be signed in to my Google Hangouts account all day to be able to receive calls, but the page won't actually put the MediaStream to use until I explicitly accept a call. A lot may have changed in between, and I'm not sure how mandatory constraints will be handled in this case.

(Note: this scenario is the only way to setup incoming calls using the current spec, but there might be other creative ways in which we are able to handle it, but that's a separate discussion).

> The return value from getCapabilities() is a JavaScript Object (MediaStreamConstraints) containing, for each device/media stream/channel, a list of MediaStreamConstraint keys and values.  In the trusted scenario, the browser MUST return all relevant constraints of type "min" or "max" as follows:
> - if the constraint is a "min" constraint, it must represent the smallest value of that constraint across all supported streams of the given stream type.  For example, if the constraint is "video-min-width:500", that would mean that there is no video stream with a width smaller than 500 pixels.
> - if the constraint is a "max" constraint, it must represent the largest value of that constraint across all supported streams of the given stream type.  For example, if the constraint is "video-max-width:1000", that would mean that there is no video stream with a width greater than 1000 pixels.

getCapabilities() is only allowed for trusted applications, correct? We should figure out if we should also specify the mechanisms by which UAs elevate privileges to put apps in the trusted ring, or if we can leave it free-form and let every UA do its thing. I'm leaning towards the latter, because on devices like desk phones all apps are likely to be trusted from the start.

Thanks!
-Anant
Received on Tuesday, 13 March 2012 17:37:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:14:59 GMT