Remove extension to getCapabilities() in favour of MediaCapabilities

[Orphis]

Rerefences to scalabilityModes in getCapabilties('video').codecs have been removed and replaced with references to the MediaCapabilities API when appropriate and an example for the MediaCapabilites API usage have been added.

The SFM capabilities description has not been updated since it is not normative or reflective of the Javascript APIs we support anyway and falls into the domain of native APIs.

Fixes: https://github.com/w3c/webrtc-svc/issues/22, https://github.com/w3c/webrtc-svc/issues/49

---

:boom: Error: 522 :boom:

PR Preview failed to build. (Last tried on Jan 20, 2023, 9:14 PM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one: :rotating_light: [Spec Generator](https://www.w3.org/2015/labs/) - Spec Generator is the web service used to build specs that rely on ReSpec. :link: [Related URL](https://labs.w3.org/spec-generator/?type=respec&url=https%3A%2F%2Fraw.githubusercontent.com%2FOrphis%2Fwebrtc-svc%2Feaf4e6cd597db9b21c300a59804ac3a8bc283b09%2Findex.html%3FisPreview%3Dtrue) _If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please [file an issue](https://github.com/tobie/pr-preview/issues/new?title=Error%20not%20surfaced%20properly&body=See%20w3c/webrtc-svc%2376.)._

[Orphis]

@dontcallmedom Do you know what's going on with the CI on this PR?

[dontcallmedom]

seems to have been a temporary hiccup, relaunching the CI fixed it

[aboba]

The PR does not modify Sections 4.2.1 addTransceiver() or 4.2.2 setParameters(), which refer togetCapabilities() to determine whether a scalabilityMode is supported. Prior to this PR, those Sections could be tested by comparing the results of setParameters() and addTransceiver() against getCapabilities(). For example, if getCapabilities() indicated that a scalabilityMode was not supported for a codec, then an attempt by setParameters() to set that scalabilityMode should fail.

I am not sure how a test can be written based on the PR. As noted in https://github.com/w3c/media-capabilities/issues/192, most of the time supported does not depend on width, height, bitrate, and framerate, but this is not the case for every browser implementation or every parameter combination.

Does the browser implementation maintain an internal slot with a list of supported scalabilityMode values for each codec? If so, is there a way for an application to determine the value of this internal slot? For example, should the application expect setParameters() to succeed for a scalabilityMode if there is some combination of width, height, bitrate and framerate for which supported will be returned in Media Capabilities?

Or can setParameters() fail based on the particular values of width, height, bitrate and framerate that are in use at a given moment? If so, how can the application determine what the offending parameters are?

[youennf]

• Having one method that provides both the codecs that are available and how they can be configured, without trial-and-error querying MediaCapabilities, seem to have several advantages.

MediaCapabilities is designed this way for privacy reasons. An async getCapabilities would probably go against that goal.

[henbos]

MediaCapabilities is designed this way for privacy reasons. An async getCapabilities would probably go against that goal.

Makes sense. What happens if the app queries MC too much?

[youennf]

Makes sense. What happens if the app queries MC too much?

It is up to the UA to put some protection when detecting such pattern (throttling at least...).

[aboba]

@henbos At the moment, it is possible to call MC on all scalabilityMode values for a given codec, without complaint: https://webrtc.internaut.com/mc/

[henbos]

Ack, so while theoretical at this point, it sounds like an app that does not want to risk throttling delaying call setup time should only query a small number of times

[aboba]

@dontcallmedom The hiccup seems to be back, CI is failing again.

[aboba]

Previous CI issues appear fixed. CI now completes successfully.