W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > October 2022

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

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
Message-ID: <issue_comment.created-1272183082-1665190651-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:59 UTC