RE: Constraints at request time (Re: Revised Constraints modification API proposal)

> From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com]
> 
> On 2012-08-23 16:03, Harald Alvestrand wrote:
> > On 08/23/2012 03:50 PM, Adam Bergkvist wrote:
> >>
> >> I've also though about this initial filtering that applying
> >> constraints before presenting device options to the user provides.
> >> However, I think we win more with the new approach than we loose.
> >>
> >> Even with constraints applied after device selection we need some
> >> small set of options/constraints to filter the device list presented
> >> to the user. We have the obvious "audio" and "video", but we may also
> >> need something to hint about camera direction where it's possible
> >> ("front"/"user" "back"/"environment"). If this proves to be a huge
> >> problem, we could also look into some quality hints here like "hd",
> >> "vga" and so on. It won't solve everything but I think it will cover
> >> a lot of cases.
> >>
> >> /Adam
> >>
> > Now I've really lost you - are you advocating applying constraints as
> > part of getUserMedia, or are you advocating not applying constraints
> > as part of getUserMedia?
> >
> > I'm not even going to consider the implications of having two
> > different data structures for constraints, one that you use on
> > getUserMedia and one that you use after getting the device; that's
> > just too gross to consider.
> 
> I don't expect getUserMedia() to only have the successCallback and
> errorCallback arguments in Travis' proposal. My understanding is that it
> would be something similar to before we had constraints. E.g.
> 
> navigator.getUserMedia({audio: true, video: true}, successCb, errorCb);
> 
> Constraints would then be applied (if necessary) in successCb at the earliest.

To be clear, it was never my intention to remove the {audio: true, video: true } 
"constraints" from getUserMedia. I'm sorry if I implied that.

Received on Thursday, 23 August 2012 19:03:06 UTC