- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Fri, 28 Aug 2020 12:07:38 +0000
- To: public-webrtc-logs@w3.org
What would be unpredictable would be web devs needing to refer to a list over which constraints can be set from `getUserMedia` or not. It also seems rather pointless since they can just call `applyConstraints` right after for the same effect. > Things are a bit simpler with applyConstraints since it starts with a device initial state that is exposed to the web page. Does it? Isn't that only if people make the effort to call `getSettings` explicitly and take those into account when specifying their constraints somehow? E.g.: ```js await track.applyConstraints(buildMyConstraintsFromSettings(track.getSettings())); ``` I don't think that's been common, until this spec at least where you're kinda forced to do that initially since the units of `pan`, `tilt` and `zoom` are unknown. However that doesn't preclude restoring settings from last visit, which should be good for the same `deviceId` at least. > step 6.6 is potentially calling the applyConstraints constraints twice for audio and video tracks, so "In a single operation" is not always guaranteed. ... [because] ... step 6.6 is also handling the case of an error. It also says about these steps: _"For each media type kind ... run the following sub steps, **preferably at the same time**"_ So it seems possible to implement this where all constraints failures from step 6.6. are dealt with before `pan`, `tilt` and `zoom` move the camera, or by simply doing audio first. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-image/issues/229#issuecomment-682489325 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 28 August 2020 12:07:40 UTC