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

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

From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Date: Mon, 28 Jan 2019 18:46:04 +0100
To: public-webrtc@w3.org
Message-ID: <64ea3b1c-4f66-658c-20e3-2e75e8535649@gmail.com>
I am not reusing transceivers for sending and creating new ones instead 
for the exact reasons you are mentioning, but could we use 
transceiver.stop() in this case and add a new transciver instead (that 
would reuse the mid, right?)?

(Note: Last time I checked, stop was not implemented in chrome, so not 
sure how it behaves at all).

Best regards

On 28/01/2019 17:29, IƱaki Baz Castillo wrote:
> 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?
Received on Monday, 28 January 2019 17:41:55 UTC

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