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

Re: [webrtc-pc] Change stream associations (#2658)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Tue, 06 Dec 2022 21:33:56 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1340040118-1670362434-sysbot+gh@w3.org>
> [RTCRtpSender.setStreams](https://developer.mozilla.org/en-US/docs/Web/API/RTCRtpSender/setStreams#description) docs says:
> > setStreams() is purely additive. It doesn't remove the track from any streams; it adds it to new ones.

MDN is wrong. [setStreams](https://www.w3.org/TR/webrtc/#dom-rtcrtpsender-setstreams) is NOT additive. You may be running into [crbug 1396429](https://crbug.com/1396429) in Chrome. So I'm closing this.

@alvestrand's advice is good, at least until setStreams has been implemented correctly in more browsers.

> Can the receiver dynamically change the associated stream multiple times? For example, when the active speaker changes.

RTCPeerConnection is track based, so you can put `receiver.track` in whatever streams you like. E.g.
video.srcObject = new MediaStream([myVideoTransceiver.receiver.track, myAudioTransceiver.receiver.track]);
You can also use [addTrack](https://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediastream-addtrack) and [removeTrack](https://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediastream-removetrack) to add or remove your track from whatever streams you want (streams are just dumb containers).

> Does not setting the streams at the sender side has any effect on the receiver?

Only that the receiver will no longer create streams as a convenience for you or automatically add/remove `transceiver.receiver.track` to/from them based on currentDirection.

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2658#issuecomment-1340040118 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 6 December 2022 21:33:58 UTC

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