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


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:


> 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