Re: Can constraints constrain by default?

The old LISP programmer in me wants to say that we could make 
MediaStreamConstraints an array of MediaTrackConstraintSet, each of 
which specifies what type of device it wants via mediaSource.  This is 
pretty general, allows for any number of devices to be used - and is  
overkill for the vast majority of apps people will build.  So maybe 
we're stuck with videoN.  One problem though is that in the current spec 
we define sourceType and sourceID to apply to both audio and video 
tracks.   It would be pretty annoying to have sourceType default to 
'camera' for an audio track.

- Jim


On 4/2/2014 8:16 PM, Jan-Ivar Bruaroey wrote:
> This came up while discussing screensharing as a video constraint. 
> Google uses chromeMediaSource:'screen' right now.
>
> This raises a question about how constraints work. Constraints are 
> limits that (in the case of video) constrain a pool of cameras (and 
> now screensharing sources), implying that when you don't constrain the 
> pool, you may get any camera (or screensharing source) in the pool.
>
> But people should never get screensharing when they expected a camera 
> or vice versa. One way for this to work, I suppose, is to say that the 
> mediaSource member defaults to 'camera'.
>
> But we haven't defined what it means for a constraint to have a 
> default value. Luckily, with dictionaries, WebIDL defines this for us: 
> Our WebIDL compiler generates binding code that makes a default value 
> indistinguishable from a passed-in value.
>
> What this means is that whatever constraints you specify (including 
> none), unless you explicitly specify the mediaSource constraint, it 
> would be as if you had specified mediaSource:'camera'.
>
> This sort of works and effectively creates two pools, and you can only 
> access one or the other, depending on this constraint. It's a little 
> odd perhaps that, while you could still argue that individual 
> constraints still constrain, the overall process isn't solely about 
> narrowing choices anymore, but picking pools of choices at the same time.
>
> Are we OK with this behavior and use? Does it merit mention in the 
> spec? Anyone see any concerns? It seems to fall out naturally (if we 
> use dictionaries at least), but I may have missed something. Anyone 
> see any major issues?
>
> .: Jan-Ivar :.
>
> PS: Speaking of screen-sharing, another way to go might be to use 
> screen:true, i.e. a new top-level type along audio and video. This 
> would avoid the question in the subject (for a while perhaps). It 
> might also work better should people want access to camera, mic AND 
> screen in the same call, though arguably, people should be able to 
> specify multiple video streams someday (how? can't have two fields 
> named 'video'! Perhaps 'video2' ? ugh)
>
>

-- 
Jim Barnett
Genesys

Received on Thursday, 3 April 2014 02:28:05 UTC