Re: Proposal on how to introduce constraints in getUserMedia()

I really like the sound of this. I think it's important to keep a simple API such as {'video': true, 'audio': true) with more advanced features as an optional extra.

Thanks Adam. 

Paul. 






On Thursday, 22 March 2012 at 12:15, Adam Bergkvist wrote:

> Hi
> 
> There's a thread on public-webrtc [1] about how to focus our work and 
> prioritize functionality for version one. Parts of that discussion has 
> moved on to deal with how constraints can be introduced in 
> getUserMedia(). This mail is intended as input to that discussion but 
> this list is more appropriate for such a discussion.
> 
> ---
> 
> One way forward could be to have the constraints dictionary as a member 
> of the existing MediaStreamOptions dictionary.
> 
> void getUserMedia (MediaStreamOptions? options,
> NavigatorUserMediaSuccessCallback? successCb,
> optional NavigatorUserMediaErrorCallback? errorCb);
> 
> dictionary MediaStreamOptions {
> boolean audio;
> boolean video;
> MediaStreamConstraints? constraints;
> };
> 
> This actually has some benefits:
> - We can add the constraints dictionary member to MediaStreamOptions at 
> any time without breaking existing code.
> - Constraints have a specific syntax (described in the constraints 
> registry draft [2]) so we can keep the simple "audio" and "video" keys 
> if we have them in a separate dictionary.
> - We will be more aligned with DOM APIs such as Geolocation which have 
> an optional structure for advanced options.
> 
> BR
> Adam
> 
> ---
> [1] http://lists.w3.org/Archives/Public/public-webrtc/2012Mar/0075.html
> 
> [2] 
> http://tools.ietf.org/id/draft-burnett-rtcweb-constraints-registry-00.txt

Received on Thursday, 22 March 2012 14:52:03 UTC