-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove extension to getCapabilities() in favour of MediaCapabilities #76
Conversation
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.
@dontcallmedom Do you know what's going on with the CI on this PR? |
seems to have been a temporary hiccup, relaunching the CI fixed it |
The PR does not modify Sections 4.2.1 addTransceiver() or 4.2.2 setParameters(), which refer to I am not sure how a test can be written based on the PR. As noted in w3c/media-capabilities#192, most of the time Does the browser implementation maintain an internal slot with a list of supported Or can |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on updating the spec match what is shipping so I'm happy to approve.
That being said...
- From a casual reading of SVC getCapabilities() is redundant with Media Capabilities query #49, I can't tell if removing scalabilityModes from getCapabilities() is a good or bad thing.
- 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. I proposed an async version here which might help solve other issues as well.
But I don't have a strong opinion. This seems to already have been discussed at lengths and if MC already gets the job done then perhaps we're just talking about ergonomics. I did have some concerns about feature detection earlier, but those seem to have been overblown.
Perhaps "Should there exist an async getCapabilities()" deserves a separate issue?
MediaCapabilities is designed this way for privacy reasons. |
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...). |
@henbos At the moment, it is possible to call MC on all |
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 |
@dontcallmedom The hiccup seems to be back, CI is failing again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added lines 241-246 (text looks to have been deleted by mistake). Also fixed references to Section 9 (should be Section 10), and provided a link to the definition of "simulcast envelope" in WebRTC-PC.
Previous CI issues appear fixed. CI now completes successfully. |
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: #22, #49
💥 Error: 522 💥
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:
🚨 Spec Generator - Spec Generator is the web service used to build specs that rely on ReSpec.
🔗 Related URL
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.