Add unidirectional codec test support in WPT using H264. - #49421
Merged
Conversation
According to PR[1], setCodecPreferences() should accept any codec that is *either* in in RTCRtpSender.getCapabilities() *or* RTCRtpReceiver.getCapabilities(); the actual filtering happens when the SDP is generated based on the transceiver direction. This makes it possible for a sendonly transceiver to offer a sendonly codec and for a recvonly transceiver to offer a recvonly codec, as opposed to forcing that all codecs must be receive-capable at createOffer() time which is the old and currently implemented behavior, hence the failing test. (In the old model, pc1 would be forced to not have any preferences and pc2 be forced to call setCodecPreferences() before createAnswer() on behalf of pc1 in case that pc1 is sendonly.) Due to the limitation that on a local page both pc1 and pc2 have the same capabilities, the remote SDP is modified to make pc1 think that pc2 supports the codec being negotiated in the other direction. Because getCapabilities() is device-specific, we skip the tests (using [PRECONDITION_FAILED]) if the necessary capabilities (= unidirectional H264) is not supported but the tests work e.g. on MacBook M1 Pro. [1] w3c/webrtc-pc#3018 Bug: chromium:379551577 Change-Id: I4e1ce5371db66de83d42cbd2ba2eca5d703661d3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6054227 Reviewed-by: Harald Alvestrand <hta@chromium.org> Commit-Queue: Henrik Boström <hbos@chromium.org> Cr-Commit-Position: refs/heads/main@{#1389353}
wpt-pr-bot
approved these changes
Nov 28, 2024
wpt-pr-bot
left a comment
Collaborator
There was a problem hiding this comment.
The review process for this patch is being conducted in the Chromium project.
Contributor
|
@dontcallmedom Does one have to manually click the merge button here or do we just wait a bit longer? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
According to PR[1], setCodecPreferences() should accept any codec that
is either in in RTCRtpSender.getCapabilities() or
RTCRtpReceiver.getCapabilities(); the actual filtering happens when the
SDP is generated based on the transceiver direction.
This makes it possible for a sendonly transceiver to offer a sendonly
codec and for a recvonly transceiver to offer a recvonly codec, as
opposed to forcing that all codecs must be receive-capable at
createOffer() time which is the old and currently implemented behavior,
hence the failing test. (In the old model, pc1 would be forced to not
have any preferences and pc2 be forced to call setCodecPreferences()
before createAnswer() on behalf of pc1 in case that pc1 is sendonly.)
Due to the limitation that on a local page both pc1 and pc2 have the
same capabilities, the remote SDP is modified to make pc1 think that
pc2 supports the codec being negotiated in the other direction.
Because getCapabilities() is device-specific, we skip the tests (using
[PRECONDITION_FAILED]) if the necessary capabilities (= unidirectional
H264) is not supported but the tests work e.g. on MacBook M1 Pro.
[1] w3c/webrtc-pc#3018
Bug: chromium:379551577
Change-Id: I4e1ce5371db66de83d42cbd2ba2eca5d703661d3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6054227
Reviewed-by: Harald Alvestrand <hta@chromium.org>
Commit-Queue: Henrik Boström <hbos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1389353}