Reland "Add unidirectional codec test support in WPT using H264."
This is a reland of commit 6d384616505dd60b218e392d1e03836d4965248d
TO SHERIFFS: If this fails on other bots not covered by expectations,
please update TestExpectations and CC hbos rather than reverting CL.
Depending on HW capabilities of the bot running, these tests will either
run or "skip" as [PRECONDITION_FAILED]. In particular, the send-only
test case is either expected to FAIL or to [PRECONDITION_FAILED]. On
the Windows bot on the CQ it [PRECONDITION_FAILED] but on waterfall bot
win11-arm64-rel it FAILs instead[1]. This is not a bug, it's just a
matter of needing to update test expectations.
Let's reland with TestExpectations of win11 PASS/FAIL to allow both CQ
and waterfall behavior. If this sticks we can try replacing that with
third_party/blink/web_tests/platform/win11-arm64/ specific -expected.txt
files but let's make sure the baseline test coverage is not reverted
first.
Original change's description:
Add unidirectional codec test support in WPT using H264.
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.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}
Bug: chromium:379551577, chromium:381378075
Change-Id: I54608d45d259bafde375fdb8da371ca45e69e5f3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6054131
Auto-Submit: Henrik Boström hbos@chromium.org
Reviewed-by: Harald Alvestrand hta@chromium.org
Commit-Queue: Harald Alvestrand hta@chromium.org
Commit-Queue: Henrik Boström hbos@chromium.org
Cr-Commit-Position: refs/heads/main@{#1389697}