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

To not change current behavior of the setParameters() method, I would be 
in favor of a transponder.reset() with the same parameters as 
addTranscoder() that restarts the transcoder with the new parameters via 
a renegotiation.

On 30/01/2019 15:52, Henrik Boström wrote:
> You can mark all encodings except one inactive. It's not exactly the 
> same (rid is used, the other endpoint still has to be prepared for 
> other layers as previously negotiated), but does it matter?
>
> replaceTrack() and setParameters() make changes in a way that doesn't 
> require renegotiation. If you're changing the direction anyway you 
> could argue that we might as well renegotiate what layers to support, 
> but it would require some special logic about when setParameters() can 
> be called without danger and it might limit what you can do with 
> direction.
>
> On Mon, Jan 28, 2019 at 6:43 PM Sergio Garcia Murillo 
> <sergio.garcia.murillo@gmail.com 
> <mailto:sergio.garcia.murillo@gmail.com>> wrote:
>
>     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
>     Sergio
>
>
>     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?
>     >
>     >
>
>