- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Fri, 08 Mar 2019 08:48:58 +0000
- To: public-webrtc-logs@w3.org
> Circular reasoning. They may both be useless. They don't validate each other. :wink: That's part of my point, I'm questioning everything now. Overconstraining for a remote track doesn't make much sense to me because it doesn't _just_ inform you that conditions are not met, it _mutes_ the track (which has a different meaning for WebRTC's remote tracks). But I couldn't think of a how it would overconstrain if not for remote tracks. Given your frameRate example, I guess this makes "more" sense when capturing, but again why would you want to mute the track? Probably as to not spam the application with overconstrained events, but it makes overconstrained mean not just "FYI, diagnostics", but "hey, something is WRONG, and you need to do something about it, this track is now silenced". I think it's up to the application whether or not to mute the track, otherwise this is a foot-gun. > - It's redundant: just measure the output directly and react to it. If this is true I suggest we remove overconstrained event. @guidou -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/573#issuecomment-470852348 using your GitHub account
Received on Friday, 8 March 2019 08:48:59 UTC