Re: [webrtc-pc] What is the intended behavior of rollback of remote simulcast offer? (#2764)

> I've [tested this]( and Chrome removes the encodings while Safari doesn't.

To clarify, all I could test until [crbug 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]( 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 using your GitHub account

Sent via github-notify-ml as configured in

Received on Saturday, 8 October 2022 00:57:34 UTC