- 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