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>
Hi,

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
`transceiver.sender.setParameters()`.

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

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
<ibc@aliax.net>
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