Re: Capabilities vs SupportedConstraints

On 10/31/14, 9:12 PM, Rob Manson wrote:
> this might be a stupid question...but what's the real difference 
> between Capabilities and SupportedConstraints.

No, good question.

Capabilities = what's actually available in your hardware.
SupportedConstraints = what your browser is equipped to detect (read: 
understands).

For example: To know unequivocally that a user has no 75Hz cameras, 
SupportedConstraints().frameRate must be non-zero and getUserMedia({ 
video: {frameRate: { exact: 75 } }) must reject with NotSupportedError. 
(Replace frameRate with a capability that's not mandatory to implement).

Another difference - which you mention - is that SupportedConstraints is 
global to the browser, while Capabilities is always about specific 
hardware. There is no API to get the aggregate capabilities of your 
system (but there could have been, which makes your next point valid I 
think).

> It seems to me that under the hood Capabilities and 
> SupportedConstraints are effectively the same concept.
>
> I can see why there might be some fingerprinting/privacy issues if the 
> method that hung off MediaDevices returned the full set of 
> SupportedConstraints (e.g. before the stream permissions were granted, 
> etc.). But calling these two things by completely different (but 
> somewhat interchangeable) names seems a bit confusing.

I think I agree (in spite of the different usage). One certainly appears 
like a less opaque version of the other. In hindsight, the concept of 
"constraint" may have upstaged the concept of "capability", when the 
latter is actually the currency of interest.

Last call is imminent, but we do have an action item for editors to 
clarify the terms used in this section, and I agree with you it is 
needed (I already have a PR in this area fwiw [1])

What if we renamed MediaTrackConstraintSet (mouthful) to MediaCapabilities?

dictionary MediaCapabilities {
     ConstrainLong      width;
     ConstrainLong      height;
     ConstrainDouble    aspectRatio;
     ConstrainDouble    frameRate;
     ConstrainDOMString facingMode;
     ConstrainDouble    volume;
     ConstrainLong      sampleRate;
     ConstrainLong      sampleSize;
     ConstrainBoolean   echoCancellation;
     ConstrainDOMString deviceId;
     ConstrainDOMString groupId;
};

dictionary MediaTrackConstraints : MediaCapabilities {
     sequence<MediaCapabilities> advanced;
};

Those seem like more correct types to me. After all, we're constraining 
in the capability space.

Doing so would have several benefits as I see it:

 1. getCapabilities() would return MediaCapabilities, which seems right [1].

 2. We avoid silly questions like "is volume a constraint?", when the
    right question is "is volume an available capability?"

While most mutable capabilities serve both camera selection and 
mutual-access-arbitration, some capabilities (like facingMode) are 
invariable and serve only camera selection, while others (like volume) 
serve only mutual-access-arbitration.

As for what SupportedConstraints() should return or be called, I argue 
in the same PR for returning what effectively amounts to a 
MediaCapabilities with "opaque" values. With your observation, it might 
be interesting to explore whether it could return something more 
detailed once permission is granted (somewhat like enumerateDevices does).

Thoughts?

.: Jan-Ivar :.

[1] https://github.com/w3c/mediacapture-main/pull/37