- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Oct 2021 06:58:30 +0000
- To: public-webrtc-logs@w3.org
In general, we should just have one way of doing things. I understand there might be legacy reasons for getCapabilities and MC redundancy, but WebRTC-SVC is a new spec. getCapabilities has known issues with regards to codecs: - getCapabilities is synchronous while codec enumeration is usually asynchronous, see discussion about getCapabilities results changing after the first createOffer/createAnswer call - Applications might want to know about SVC referenceScaling support, which is only in MC. - Applications might want to know whether a given codec is power efficient or not, which is only in MC. If MC is not good enough for WebRTC applications to easily and precisely select their preferred codec, we should try to improve MC directly instead of patching it with getCapabilities. > WebRTC-SVC doesn't have the same level of privacy concerns. Getting a list of codecs is a known fingerprinting surface, exposing scalability modes extends this fingerprinting surface. We should treat it is as such and apply https://w3c.github.io/fingerprinting-guidance/#api-minimization. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/webrtc-svc/issues/49#issuecomment-947383023 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 October 2021 06:58:32 UTC