Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Constrainable properties on remote tracks are under-specified #2121
What behaviors specific to remote peer connection tracks are available through the constraints APIs? There's a single paragraph on the topic, and it doesn't say.
From @guidou in #2109 (comment), Chrome appears to have implemented something, so we should probably specify it, like we did in w3c/mediacapture-screen-share#31. Otherwise, the next question might be why don't we support whiteBalanceMode?
Observations or starting point-opinions:
Definition: "White balance mode is a setting that cameras use to adjust for different color temperatures."
I think a lot of this boils down to if you view "applyConstraints()" as means to change configurations of a source or filter/transform what the source provides you with. The former is not applicable to remote tracks, the latter is.
We may save a lot of time arguing if we can pinpoint what "applyConstraints()" should mean with regards to this!
Side-discussion, though perhaps we should leave this one until later, is what to do if a track gets overconstrained? Given that mute is a possible side-effect of setRemoteDescription(), I am opposed to allowing remote tracks to become muted for other reasons. Two possibilties I see:
My 2 cents.
With respect to the behavior of applyConstraints() as well as gUM constraints, my understanding is that they should behave as filters, not as settings. This means that for local tracks it makes sense to filter which device should be used based on some criteria but with remote tracks this seems blurry, mostly because such parameters are anyway negotiated (hence, I am not sure why, after negotiation one should further filter for the right track).
It's clearly both. Constraints outsource (no pun intended) user requirements from a source to its sink(s); a classic "put the control surface on the result object" thing. A
It's an API. We're in an ugly spot of asking: "What behavior should this API produce?", when we need to ask: "What remote track use-cases must be solved (and what's the best API for them)?"
In the case of w3c/mediacapture-screen-share#31 (comment) we had those use-cases.
It doesn't. A camera track is inherently and observably different from a screen-share track here:
There are other differences as well: screenshare tracks never fire
If "defensive" means specifying how
I agree with @jan-ivar's comment.