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

Reusing a transceiver to send a new track with different encodings (WANNA DIE)

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Mon, 28 Jan 2019 17:29:25 +0100
Message-ID: <CALiegf=g6rOUrByZNR1ykJFGcmHOCQgfYRNJyKLM3BR3dd3ZtQ@mail.gmail.com>
To: WebRTC WG <public-webrtc@w3.org>

It seems that reusing a transceiver is a pain. Use case:

1) Create a transceiver for sending video.

2) Pass 3 encodings in the `addTransceiver()` call or later in

3) Later "stop" the sender by stopping the track and calling
transceiver.sender.replaceTrack(null) and transceiver.direction =

4) Reuse the transceiver to send a new video, now without simulcast.
Do it via transceiver.sender.replaceTrack(newTrack),
transceiver.direction = "sendonly" and
transceiver.sender.setParameters(newEncodings), where `newEncodings`
is an array with just one encoding (no simulcast desired).

According to the spec [*] this is not valid:

[*] https://www.w3.org/TR/webrtc/#dom-rtcrtpsender-setparameters

> 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.  <==== THIS

So reusing a transceiver is just a pain because having to reuse
previous encodings is not friendly at all.

Yes, of course, I could initially set 20 encodings and set
active=false in most of them, so later I can switch them on/off
individually to get the "desired" behavior. No. This is a pint.

Can we please move to WebRTC 2.0 and get rid of SDP semantics and
artificial limitations due to the nature of SDP?

Iñaki Baz Castillo
Received on Monday, 28 January 2019 16:30:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:46 UTC