W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2019

[webrtc-pc] Need something such as rtpSender.reset() (#2087)

From: Iñaki Baz Castillo via GitHub <sysbot+gh@w3.org>
Date: Mon, 28 Jan 2019 18:58:21 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-403959024-1548701899-sysbot+gh@w3.org>
ibc has just created a new issue for https://github.com/w3c/webrtc-pc:

== Need something such as rtpSender.reset() ==
### Use case

1) Create a transceiver for sending video with simulcast:

const transceiver = pc.addTransceiver(track, {
  direction: 'sendonly',
  sendEncodings: [
    { rid: '111', active: true, maxBitrate: 111111 },
    { rid: '222', active: true, maxBitrate: 222222 },
    { rid: '333', active: true, maxBitrate: 333333 }

// or pass those encodings via transceiver.sender.setParameters()

2) Later deactivate the video sender:

await transceiver.sender.replaceTrack(null);
transceiver.direction = "inactive";

3) Reuse the `transceiver` to send a new video, now without simulcast:

await transceiver.sender.replaceTrack(newTrack);
transceiver.direction = "sendonly";

const parameters = transceiver.sender.getParameters();
const newEncodings = [
  { active: true, maxBitrate: 222222 }

await transceiver.sender.setParameters({ ...parameters, encodings: newEncodings });

### The problem

According to the [spec](https://www.w3.org/TR/webrtc/#dom-rtcrtpsender-setparameters) this is not valid:

> 6.3 Let N be the number of RTCRtpEncodingParameters stored in sender's internal [[SendEncodings]] slot. If any of the following conditions are met, return a promise rejected with a newly createdInvalidModificationError:
> 6.4 encodings.length is different from N.

So reusing a transceiver becomes a pain because we must "accept" the previously set `encodings` and now we can just "mangle" some of them to accomplish with our new and probably unrelated needs.

Yes, of course, weI could initially set 20 `encodings` and set `active: false` in most of them, so later we can switch them on/off individually to get the "desired" behavior. This is far from "elegant".

### Proposal

Have a new `rtpSender.reset()` or `transceiver.resetSender()` method that replaces the previous `RtpSender` with a fresh one, without dependencies or settings based on previous usages.

Of course, such a `reset()` method should throw if called while the transceiver has `direction` "sendonly" or "sendrecv".

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2087 using your GitHub account
Received on Monday, 28 January 2019 18:58:22 UTC

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