Re: [webrtc-extensions] Add normative steps to getCapabilities() or deprecate it in favor of an async API (#57)

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 using your GitHub account

Sent via github-notify-ml as configured in

Received on Thursday, 17 December 2020 10:29:16 UTC