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}