- From: Eero Häkkinen via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Mar 2023 13:55:10 +0000
- To: public-webrtc-logs@w3.org
One option is also to change the meaning of a _pan/tilt/zoom: false_ constraint. My reading of the current fitness distance algorithm is that `pan: true` is an exact (in advanced constraint sets) or ideal (in the basic constraint set) constraint for a pan-capable device whereas `pan: false` is an exact (in advanced constraint sets) or ideal (in the basic constraint set) constraint for a pan-incapable device. That kind of makes sense. False and true are antonyms and so are pan-capable and pan-incapable. But usually it is not question about whether a site wants a pan-capable device or a pan-incapable device but whether a site wants a pan-capable device or not (i.e. it does not matter whether the device is pan-capable or pan-incapable). So it might make more sense to refine the fitness distance algorithm so that `pan: true` would still be an exact (in advanced constraint sets) or ideal (in the basic constraint set) constraint for a pan-capable device but `pan: false` would not constrain anything (similar to that `facingMode: []` does not constrain anything). That would also match the behavior of the the only current implementation (Chrome). This would also simplify the fitness distance algorithm as the `(boolean or ConstrainDouble)` case could be handled fully after the `If the settings dictionary cannot support any value for the property, the fitness distance is 1.` step. -- GitHub Notification of comment by eehakkin Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/933#issuecomment-1460190074 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 March 2023 13:55:12 UTC