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

Transceivers, on the surface, sound harmless. But superfluous amounts of
transceivers has, I've heard, been a performance issue due to the
instantiation of encoders and decoders and whatnot.
I've been holding off on stop() due to spec work, but being able to stop
them would be good for this reason. I'm not sure why we keep stopped
transceivers around.

Assuming you can stop transceivers, reusing transceivers would only be
useful in cases where you avoid renegotiation. If you renegotiate, it
doesn't matter if you reuse or create a new one. If you don't renegotiate,
you can't change the simulcast envelope (number of layers) anyway.

On Thu, Jan 31, 2019 at 9:19 AM Harald Alvestrand <harald@alvestrand.no>
wrote:

> I'm not sure why anyone would bother reusing a transceiver. It's just a
> data structure; throw it away (with .stop() once implemented) and start
> a new one.
>
> Den 28.01.2019 18:46, skrev Sergio Garcia Murillo:
> > 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?)?
>
> Changing the MID is interpreted as throwing away the old transceiver and
> starting a new one. Reusing the MID would be interpreted as continuing
> to use the old transceiver on the other end, so no, you can't get there
> from here.
>
> >
> > (Note: Last time I checked, stop was not implemented in chrome, so not
> > sure how it behaves at all).
>
> Henrik has been holding off on stop() while the spec was being reworked.
>
> >
> > 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?
> >>
> >>
> >
> >
>
>
>