- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Thu, 17 Dec 2020 10:29:15 +0000
- To: public-webrtc-logs@w3.org
getCapabilities() is an "optimistic view of the capabilities". Because it is a static method it cannot do things on a per-peer connection basis. So it doesn't matter if the remote end only offered you VP8 or if you locally said you only care about VP9, you would still see that you are capable of doing VP8, VP9 and H264 if 1) you can do this, and 2) the implementation knows this. It's just what you could do, not what is on offer. So the question of interest is: what do you know, and when? In fact, a HW agnostic implementation could be over-optimistic and report HW-only codecs on a device that doesn't do HW. "If I don't know this _isn't_ supported, I could say that it _is_ (even if it turns out that I'm wrong!)" is, as far as I can tell, a valid interpretation from the words of the specs, but we did not intend that. In the end this only affects the "codec preferences" that is "input" to the "JSEP algorithms" so anything that doesn't break JSEP would probably be okay-ish to do, but depending on what we do would have great consequences on the usefulness of the API. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/57#issuecomment-747353109 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 17 December 2020 10:29:16 UTC