Cababilities need to clearly specify that they are constant over time

[dontcallmedom]

Initially reported in bugzilla by Harald Alvestrand 2014-10-16 13:07:45 UTC

From Jan-Ivar, in bug 25777:

While examples are nice, I would argue they're no replacement for specification.

Are capabilities accurate?

While it is possible to deduce from the applyConstraints algorithm [1] that capabilities are allowed to be a super-set of what the UA supports, I find no mention of this where Capabilities is defined [2].

I've read the definition a couple of times, and even though it uses the word "subset" four times in one paragraph, it still seems to equate what the capabilities read with what "the UA supports", which doesn't allow for capabilities to be either-or (e.g. super framerate OR super resolution).

I think it would help implementations if the spec stated that returned capabilities must a set or super-set of what the UA supports.

Are capabilities constant?

I find conflicting text on this in the spec:

"The UA may choose new settings for the Capabilities of the object at any time. When it does so it must attempt to satisfy the current Constraints, in the manner described in the algorithm above." [2]

vs.

"Source capabilities are effectively constant. Applications should be able to depend on a specific source having the same capabilities for any session." [3]

[1] http://w3c.github.io/mediacapture-main/getusermedia.html#dfn-applyconstraints
[2] http://w3c.github.io/mediacapture-main/getusermedia.html#capabilities
[3] http://w3c.github.io/mediacapture-main/getusermedia.html#terminology

[dontcallmedom]

Comment by Harald Alvestrand 2014-10-16 13:08:35 UTC

From Harald, on mailing list October 10:

I think the definition is intended to say that it be a superset.
That's what the example was supposed to demonstrate: even though only two resolutions are supported, the values given are ranges.

Are capabilities constant?

I find conflicting text on this in the spec:

"The UA may choose new settings for the Capabilities of the object at any time.
When it does so it must attempt to satisfy the current Constraints, in the
manner described in the algorithm above." [2]

I think "new settings for the Capabilities of the object" was meant to be parsed as

(new settings for) (the Capabilities of the object)

ie it is the settings that are new. The capabilities remain unchanged.
(and I think capitalizing Capabilities here is probably misleading).

[dontcallmedom]

Comment by Harald Alvestrand 2014-11-20 15:49:32 UTC

In the quoted sentence, "Capabilities" should be "constrainable properties".

Capabilities can change - for example if a camera is plugged in or unplugged - so they're not strictly constant. But for most purposes, it makes sense to treat them as constant.

Will be covered by the consistency review/rewrite.

[stefhak]

Assigning to Dan based on "Will be covered by the consistency review/rewrite."

[burnburn]

I've cleaned up more of the text that used the term Capability to mean 'constrainable property'. Additionally, the text does now seem to have wording that Capabilities don't tend to change. However, I'm not at all sure how to make any other changes regarding Capabilities being a super- or sub-set of what the (User Agent/device) supports. Some specific suggestions would be good, if still necessary. If the suggestions have already been made in a very recent issue or PR that I just haven't gotten to yet, just reference them here.

[burnburn]

Thanks Jan-Ivar. I'm fine with this but want to hear confirmation from Adam and Cullen as well.

[dontcallmedom]

paging @adam-be and @fluffy per @burnburn comment above

[adam-be]

What happens in the case when, for example, a camera can perform better in good light conditions? Should the capabilities reflect the device's capabilities in the ideal case, and as a consequence, it may not be possible to use the best value at a time where conditions aren't perfect. Or should the capabilities change? I'm kind of leaning towards stable capabilities, since a script needs to deal with overconstrained anyhow.

[jan-ivar]

@adam-be I think it should reflect the max possible on each feature-axis, even if no combination is real, just like a camera might claim:

width:{ min:320, max:1920 }, height:{ min:200, max:1080 }, frameRate{ min:2, max:100 }

even though 1920x1080x100fps is not supported, but, say, 320x200x100fps is. But good question, as this is probably where the "constant" language came from, is my guess.

[jan-ivar]

@adam-be we have no constraint for changing the lighting conditions, but I think it makes sense to follow the same logic even when constraints are external.

Update: I'm less sure of my stance as I think this through - it's a bit odd if constraining on the sole property of interest does not yield the property - but I think I still vote for stable. Another tab may have since grabbed the camera and is the cause of external constraints, or lighting conditions may improve, so yeah so there is no guarantee against being overconstrained for whatever reason.

[alvestrand]

Closing this bug, since its title is not clearly relevant to the discussion in the bug. Please raise another more specific bug if there is still a problem that needs solving.