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

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> 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?
> >
> >
>
>
>