- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Jun 2019 15:41:12 +0000
- To: public-webrtc-logs@w3.org
> I think the support of these constraints should be made optional, not mandatory. If we want to further beef up the support of constraints, a compelling use case would be useful. > > Also, if the implementation is generic enough to be applicable to all video tracks, I am not sure it makes sense to special case webrtc-pc remote tracks. The intent is not to do more "special-casing" of webrtc tracks but less. I am not proposing we add new constraints to remote tracks unless there is a strong use case for it that has to be argued for separately. The constraints listed in this PR are ones generic enough to be applicable to any video track, which is why Chrome shipped them for webrtc tracks when the spec was unclear about what is or is not applicable, and our implementors though that they were because they were generic. I think we should either say "constraints X, Y and Z are applicable and here's how: (description here that works with a generic implementation for any video track, so that implementations can do the same thing that they are already doing for gUM tracks)" or we should say "no constraints are applicable to remote tracks". I'm trying to get the spec to match Chrome. It is also valid that Chrome conforms by removing its constraints support for remote tracks. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2188#issuecomment-499138475 using your GitHub account
Received on Wednesday, 5 June 2019 15:41:20 UTC