- From: guidou via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Mar 2019 15:18:16 +0000
- To: public-webrtc-logs@w3.org
> It doesn't specify _how_ it should work. Implementors should not have to infer this. I think there's precedent here in [w3c/mediacapture-screen-share#31](https://github.com/w3c/mediacapture-screen-share/issues/31).
The getUserMedia spec specifies pretty well how it should work. If it shouldn't work as explained in the getUserMedia spec, then the whole 9.3.1 section should be removed or rewritten.
>
> _MediaTrackSupportedConstraints_ is returned from [navigator.mediaDevices.getSupportedConstraints()](https://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediadevices-getsupportedconstraints). How exactly is it relevant to RTCPeerConnection?
>
> Should the following blank the remote track and fire `overconstrainederror` and ?
>
> ```js
> await transceiver.receiver.track.applyConstraints({width: {min: 1280}}); // succeeds
> transceiver.receiver.track.onoverconstrainederror = () => { /* should this fire? */ };
> // Network conditions or other side using replaceTrack causes lower resolution to appear
> ```
Yes, it should fire. And, BTW, Chrome is implementing that behavior.
--
GitHub Notification of comment by guidou
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2109#issuecomment-470566522 using your GitHub account
Received on Thursday, 7 March 2019 15:18:19 UTC