Filter codecs preferences on transceiver direction #3018

henbos · 2024-11-07T12:48:57Z

As decided by the WG, this PR implements Proposal A at TPAC, i.e:

A sendonly transceiver can prefer sendonly codecs.
A recvonly transceiver can prefer recvonly codecs.
A sendrecv transceiver can only prefer codecs that we can both send and receive with. If you want to use both sendonly codecs and recvonly codecs you need to have two transceivers.

This is supported via filtering based on RTCRtpTransceiver.direction. In addition, the case where filtering results in an empty codec preferences this is treated as "no preference" as per Proposal A at Virtual Interim.

Preview | Diff

henbos · 2024-11-07T12:58:18Z

amendments.json

+	"webrtc/RTCRtpTransceiver-setCodecPreferences-direction.html"
+      ],
+      "testUpdates": [
+        "web-platform-tests/wpt#1234"


Needs updating to a real test and WPT PR, just put in a dummy value for the time being

amendments.json

webrtc.html

jan-ivar · 2024-11-07T16:06:44Z

webrtc.html

+                  remote peer. The local peer MUST be prepared to receive any
+                  codec that has been negotiated, even ones not first in the
+                  list.


We should avoid competing normative language with JSEP. One way might be to put explanations in non-normative notes.

I changed these to notes and tried to be more clear

henbos

PTAL @jan-ivar I believe I addressed your comments

webrtc.html

henbos · 2024-11-08T14:23:09Z

webrtc.html

+                  remote peer. The local peer MUST be prepared to receive any
+                  codec that has been negotiated, even ones not first in the
+                  list.


I changed these to notes and tried to be more clear

webrtc.html

henbos · 2024-11-14T08:43:01Z

@jan-ivar Have I addressed your feedback? If you could take a look before the editor's meeting

webrtc.html

amendments.json

jan-ivar

LGTM. I might add another note to cover the surprising case if the answerer receives a recvonly offer: in this case it's too late for the answerer to use setCodecPreferences to set what to send, and they need to use setParameters instead.

dontcallmedom

quoting @henbos

Add real test before landing!
(marking this as requesting changes to make sure this doesn't get overlooked)

webrtc.html

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}

This reverts commit 6d384616505dd60b218e392d1e03836d4965248d. Reason for revert: Test is failing on some bots. e.g. https://ci.chromium.org/ui/p/chromium/builders/ci/win11-arm64-rel-tests/3110/overview 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. > > [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} Bug: chromium:379551577 Change-Id: I41642a6db0ae4dc205be3f1147a179f9642fa841 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6057098 Auto-Submit: Yi Gu <yigu@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#1389544}

This is a reland of commit 6d38461 --- 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. [1] https://ci.chromium.org/ui/p/chromium/builders/ci/win11-arm64-rel-tests/b8730008657167826369/overview 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. > > [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} 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}

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. [1] https://ci.chromium.org/ui/p/chromium/builders/ci/win11-arm64-rel-tests/b8730008657167826369/overview 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. > > [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} 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}

… WPT using H264., a=testonly Automatic update from web-platform-tests 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. [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-commits: ddf44d056006ca40eb5e3ca8958eab4a627c5a42 wpt-pr: 49421

…pport in WPT using H264.", a=testonly Automatic update from web-platform-tests Revert "Add unidirectional codec test support in WPT using H264." This reverts commit 6d384616505dd60b218e392d1e03836d4965248d. Reason for revert: Test is failing on some bots. e.g. https://ci.chromium.org/ui/p/chromium/builders/ci/win11-arm64-rel-tests/3110/overview 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. > > [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} Bug: chromium:379551577 Change-Id: I41642a6db0ae4dc205be3f1147a179f9642fa841 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6057098 Auto-Submit: Yi Gu <yigu@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#1389544} -- wpt-commits: bc6fbf467e196c4f03484768c494284c8a9c3dd4 wpt-pr: 49428

…pport in WPT using H264.", a=testonly Automatic update from web-platform-tests 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. [1] https://ci.chromium.org/ui/p/chromium/builders/ci/win11-arm64-rel-tests/b8730008657167826369/overview 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. > > [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} 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} -- wpt-commits: b6af0e5b8ce153c42623baac8e33bb341e33aa18 wpt-pr: 49438

…pport in WPT using H264.", a=testonly Automatic update from web-platform-tests Revert "Add unidirectional codec test support in WPT using H264." This reverts commit 6d384616505dd60b218e392d1e03836d4965248d. Reason for revert: Test is failing on some bots. e.g. https://ci.chromium.org/ui/p/chromium/builders/ci/win11-arm64-rel-tests/3110/overview 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. > > [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} Bug: chromium:379551577 Change-Id: I41642a6db0ae4dc205be3f1147a179f9642fa841 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6057098 Auto-Submit: Yi Gu <yigu@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#1389544} -- wpt-commits: bc6fbf467e196c4f03484768c494284c8a9c3dd4 wpt-pr: 49428

…pport in WPT using H264.", a=testonly Automatic update from web-platform-tests 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. [1] https://ci.chromium.org/ui/p/chromium/builders/ci/win11-arm64-rel-tests/b8730008657167826369/overview 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. > > [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} 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} -- wpt-commits: b6af0e5b8ce153c42623baac8e33bb341e33aa18 wpt-pr: 49438

… WPT using H264., a=testonly Automatic update from web-platform-tests 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. [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 <htachromium.org> Commit-Queue: Henrik Boström <hboschromium.org> Cr-Commit-Position: refs/heads/main{#1389353} -- wpt-commits: ddf44d056006ca40eb5e3ca8958eab4a627c5a42 wpt-pr: 49421 UltraBlame original commit: 71f23cc2779b6e630c24904bff9f13459d998edd

…pport in WPT using H264.", a=testonly Automatic update from web-platform-tests Revert "Add unidirectional codec test support in WPT using H264." This reverts commit 6d384616505dd60b218e392d1e03836d4965248d. Reason for revert: Test is failing on some bots. e.g. https://ci.chromium.org/ui/p/chromium/builders/ci/win11-arm64-rel-tests/3110/overview 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. > > [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 <htachromium.org> > Commit-Queue: Henrik Boström <hboschromium.org> > Cr-Commit-Position: refs/heads/main{#1389353} Bug: chromium:379551577 Change-Id: I41642a6db0ae4dc205be3f1147a179f9642fa841 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6057098 Auto-Submit: Yi Gu <yiguchromium.org> Bot-Commit: Rubber Stamper <rubber-stamperappspot.gserviceaccount.com> Commit-Queue: Rubber Stamper <rubber-stamperappspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main{#1389544} -- wpt-commits: bc6fbf467e196c4f03484768c494284c8a9c3dd4 wpt-pr: 49428 UltraBlame original commit: dbbe286aa13433bd0bf2ae4b4767c4b87d9cfd05

…pport in WPT using H264.", a=testonly Automatic update from web-platform-tests 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. [1] https://ci.chromium.org/ui/p/chromium/builders/ci/win11-arm64-rel-tests/b8730008657167826369/overview 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. > > [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 <htachromium.org> > Commit-Queue: Henrik Boström <hboschromium.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 <hboschromium.org> Reviewed-by: Harald Alvestrand <htachromium.org> Commit-Queue: Harald Alvestrand <htachromium.org> Commit-Queue: Henrik Boström <hboschromium.org> Cr-Commit-Position: refs/heads/main{#1389697} -- wpt-commits: b6af0e5b8ce153c42623baac8e33bb341e33aa18 wpt-pr: 49438 UltraBlame original commit: fcb351942a5c6746bc7320c52069e801bda35699

… WPT using H264., a=testonly Automatic update from web-platform-tests 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. [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 <htachromium.org> Commit-Queue: Henrik Boström <hboschromium.org> Cr-Commit-Position: refs/heads/main{#1389353} -- wpt-commits: ddf44d056006ca40eb5e3ca8958eab4a627c5a42 wpt-pr: 49421 UltraBlame original commit: 71f23cc2779b6e630c24904bff9f13459d998edd

…pport in WPT using H264.", a=testonly Automatic update from web-platform-tests Revert "Add unidirectional codec test support in WPT using H264." This reverts commit 6d384616505dd60b218e392d1e03836d4965248d. Reason for revert: Test is failing on some bots. e.g. https://ci.chromium.org/ui/p/chromium/builders/ci/win11-arm64-rel-tests/3110/overview 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. > > [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 <htachromium.org> > Commit-Queue: Henrik Boström <hboschromium.org> > Cr-Commit-Position: refs/heads/main{#1389353} Bug: chromium:379551577 Change-Id: I41642a6db0ae4dc205be3f1147a179f9642fa841 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6057098 Auto-Submit: Yi Gu <yiguchromium.org> Bot-Commit: Rubber Stamper <rubber-stamperappspot.gserviceaccount.com> Commit-Queue: Rubber Stamper <rubber-stamperappspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main{#1389544} -- wpt-commits: bc6fbf467e196c4f03484768c494284c8a9c3dd4 wpt-pr: 49428 UltraBlame original commit: dbbe286aa13433bd0bf2ae4b4767c4b87d9cfd05

…pport in WPT using H264.", a=testonly Automatic update from web-platform-tests 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. [1] https://ci.chromium.org/ui/p/chromium/builders/ci/win11-arm64-rel-tests/b8730008657167826369/overview 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. > > [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 <htachromium.org> > Commit-Queue: Henrik Boström <hboschromium.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 <hboschromium.org> Reviewed-by: Harald Alvestrand <htachromium.org> Commit-Queue: Harald Alvestrand <htachromium.org> Commit-Queue: Henrik Boström <hboschromium.org> Cr-Commit-Position: refs/heads/main{#1389697} -- wpt-commits: b6af0e5b8ce153c42623baac8e33bb341e33aa18 wpt-pr: 49438 UltraBlame original commit: fcb351942a5c6746bc7320c52069e801bda35699

… WPT using H264., a=testonly Automatic update from web-platform-tests 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. [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 <htachromium.org> Commit-Queue: Henrik Boström <hboschromium.org> Cr-Commit-Position: refs/heads/main{#1389353} -- wpt-commits: ddf44d056006ca40eb5e3ca8958eab4a627c5a42 wpt-pr: 49421 UltraBlame original commit: 71f23cc2779b6e630c24904bff9f13459d998edd

…pport in WPT using H264.", a=testonly Automatic update from web-platform-tests Revert "Add unidirectional codec test support in WPT using H264." This reverts commit 6d384616505dd60b218e392d1e03836d4965248d. Reason for revert: Test is failing on some bots. e.g. https://ci.chromium.org/ui/p/chromium/builders/ci/win11-arm64-rel-tests/3110/overview 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. > > [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 <htachromium.org> > Commit-Queue: Henrik Boström <hboschromium.org> > Cr-Commit-Position: refs/heads/main{#1389353} Bug: chromium:379551577 Change-Id: I41642a6db0ae4dc205be3f1147a179f9642fa841 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6057098 Auto-Submit: Yi Gu <yiguchromium.org> Bot-Commit: Rubber Stamper <rubber-stamperappspot.gserviceaccount.com> Commit-Queue: Rubber Stamper <rubber-stamperappspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main{#1389544} -- wpt-commits: bc6fbf467e196c4f03484768c494284c8a9c3dd4 wpt-pr: 49428 UltraBlame original commit: dbbe286aa13433bd0bf2ae4b4767c4b87d9cfd05

…pport in WPT using H264.", a=testonly Automatic update from web-platform-tests 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. [1] https://ci.chromium.org/ui/p/chromium/builders/ci/win11-arm64-rel-tests/b8730008657167826369/overview 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. > > [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 <htachromium.org> > Commit-Queue: Henrik Boström <hboschromium.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 <hboschromium.org> Reviewed-by: Harald Alvestrand <htachromium.org> Commit-Queue: Harald Alvestrand <htachromium.org> Commit-Queue: Henrik Boström <hboschromium.org> Cr-Commit-Position: refs/heads/main{#1389697} -- wpt-commits: b6af0e5b8ce153c42623baac8e33bb341e33aa18 wpt-pr: 49438 UltraBlame original commit: fcb351942a5c6746bc7320c52069e801bda35699

This CL implements allowing sendonly codecs in setCodecPreferences(), i.e. this spec PR: w3c/webrtc-pc#3018. It also makes the setCodecPreferences() ignore level IDs in the filtering algorithm (but not in the sCP method call) as per this spec PR: w3c/webrtc-pc#3023. In short, before this CL, setCodecPreferences() threw an exception if a codec was preferred that is not present in receiver codec capabilities. After this CL, setCodecPreferences() allows you to prefer codecs that are *either* in the sender capabilities *or* the receiver capabilities. - This allows you to "offer to send", i.e. prefer sendonly codecs on a sendonly transceiver. - The filtering on direction is handled by RtpTransceiver::filtered_codec_preferences() which is called during SDP offer/answer (sdp_offer_answer.cc). Also as per spec changes, if this filtering results in not having any codecs to offer or answer then this results in not having any codec preferences as opposed to throwing an exception (old behavior). - Two old peer_connection_media_unittest.cc tests are updated to reflect the API failing less. This CL adds both unit tests (rtp_transceiver_unittest.cc) and full stack integration tests (peer_connection_encodings_integrationtest.cc). It also makes us pass the following Web Platform Tests in Chrome: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webrtc/protocol/h265-level-id.https.html Bug: chromium:381407888 Change-Id: I98a5ad1acccb56db0538e4d47975b8a725102c33 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374520 Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Evan Shrubsole <eshr@webrtc.org> Cr-Commit-Position: refs/heads/main@{#43788}

Upstream commit: https://webrtc.googlesource.com/src/+/79e5e721b54b3821f33be96bda3f1be69429cd53 Add unidirectional codec support ("offer to send" use case). This CL implements allowing sendonly codecs in setCodecPreferences(), i.e. this spec PR: w3c/webrtc-pc#3018. It also makes the setCodecPreferences() ignore level IDs in the filtering algorithm (but not in the sCP method call) as per this spec PR: w3c/webrtc-pc#3023. In short, before this CL, setCodecPreferences() threw an exception if a codec was preferred that is not present in receiver codec capabilities. After this CL, setCodecPreferences() allows you to prefer codecs that are *either* in the sender capabilities *or* the receiver capabilities. - This allows you to "offer to send", i.e. prefer sendonly codecs on a sendonly transceiver. - The filtering on direction is handled by RtpTransceiver::filtered_codec_preferences() which is called during SDP offer/answer (sdp_offer_answer.cc). Also as per spec changes, if this filtering results in not having any codecs to offer or answer then this results in not having any codec preferences as opposed to throwing an exception (old behavior). - Two old peer_connection_media_unittest.cc tests are updated to reflect the API failing less. This CL adds both unit tests (rtp_transceiver_unittest.cc) and full stack integration tests (peer_connection_encodings_integrationtest.cc). It also makes us pass the following Web Platform Tests in Chrome: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webrtc/protocol/h265-level-id.https.html Bug: chromium:381407888 Change-Id: I98a5ad1acccb56db0538e4d47975b8a725102c33 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374520 Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Evan Shrubsole <eshr@webrtc.org> Cr-Commit-Position: refs/heads/main@{#43788}

henbos added 4 commits November 7, 2024 13:43

Filter codecs preferences on transceiver direction

473e58d

...

5e55108

Fix wording

862c6f8

Try to make bot happy

b48c4ba

henbos commented Nov 7, 2024

View reviewed changes

henbos requested review from aboba, alvestrand and jan-ivar November 7, 2024 13:07

Address comments

3f1c705

henbos added the Needs Test Needs a WPT test label Nov 7, 2024

jan-ivar reviewed Nov 7, 2024

View reviewed changes

webrtc.html Outdated Show resolved Hide resolved

jan-ivar reviewed Nov 7, 2024

View reviewed changes

Clarify with notes

fdcd473

henbos commented Nov 8, 2024

View reviewed changes

henbos commented Nov 12, 2024

View reviewed changes

webrtc.html Show resolved Hide resolved