- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Sat, 08 Oct 2022 00:57:32 +0000
- To: public-webrtc-logs@w3.org
> I've [tested this](https://jsfiddle.net/jib1/a61txgmd/) and Chrome removes the encodings while Safari doesn't. To clarify, all I could test until [crbug 944821](https://crbug.com/944821) is fixed was the moot "the transceiver is removed' case, where the transceiver is stopped and removed from `pc.getTransceivers()` (JS can still observe the difference by holding a reference to the sender, which the fiddle does). The only non-moot case that seems important here is addTrack, and it's not possible to remove its first encoding. > it looks like rollback of a remote simulcast offer does not undo any modifications made to RTCRtpSender.[[SendEncodings]] Re-reading the OP, by "modifications" do you mean modifications made by sRD itself, or do you also include calls to setParameters() in have-remote-offer in your question? While investigating the latter, I found a [bunch of interesting pathological cases](https://jsfiddle.net/jib1/86r24x9u/): calling sRD back-to-back, first without rollback in-between and then with. In Chrome, back-to-back sRDs affect each other (even with rollback in-between), producing the same narrowing effect as if O/A completed between each call. This seems wrong. Also, parameter changes from JS survive when rollback isn't used in-between, but not when it is. Safari seems to exhibit the same behavior when rollback isn't used in-between. When rollback is used in-between the test fails because a second transceiver appears (!) A bug? cc @youennf -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2764#issuecomment-1272183082 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 8 October 2022 00:57:34 UTC