- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Mar 2019 17:18:22 +0000
- To: public-webrtc-logs@w3.org
> Yes, it should fire. And, BTW, Chrome is implementing that behavior.
@guidou When I [try it](https://jsfiddle.net/jib1/x7r4pknu/) in Chrome I get `applyConstraints not supported for this track`:
```
getSettings: {"deviceId":"b88716e4-4d43-45d3-8a96-6b6748a6a7ad","resizeMode":"none"}
getCapabilities: {"deviceId":"b88716e4-4d43-45d3-8a96-6b6748a6a7ad","facingMode":[],"resizeMode":["none","crop-and-scale"]}
OverconstrainedError: applyConstraints not supported for this track
```
I get similar output in Canary except it crashes. Is it behind a pref?
FWIW, I would not expect a peer connection to have a `deviceId`, nor mention capabilities that do not make sense, like `facingMode`. [resizeMode](https://w3c.github.io/mediacapture-main/getusermedia.html#def-constraint-resizeMode) mentions camera. A peer connection is not a camera.
Basically, this is not what I expected to see, so I think we need to specify this. I've opened https://github.com/w3c/webrtc-pc/issues/2121. Let's discuss there, and leave this issue to discuss the merits of video latency for remote tracks.
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2109#issuecomment-470614895 using your GitHub account
Received on Thursday, 7 March 2019 17:18:23 UTC