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

I realize at this point that everybody has mentioned that layers can be
disabled via the active to achieve the same effect.
I'm wondering more about the use cases. Specifically, you have video that
gets swapped out, and in one case it is video that should be sent via
simulcast, and in the next case it shouldn't use simulcast.
1. How often, do you switch the tracks, and why are you switching between
simulcast and non-simulcast?
2. Do you have a large number of transceivers? instead of reusing one
transceiver over and over and trying to make that fit both simulcast and
non-simulcast scenarios, is it possible to have two transceivers, and
stop/reuse the appropriate ones?

Henrik wrote:
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.
I believe the simulcast envelope cannot be changed even on renegotiation.
You can only remove or reject layers by omitting them from the offer/answer
or marking them as inactive (this does't necessarily change the number of
send_encodings).
Changing the envelope to add layers is not possible at all without creating
a new transceiver (i.e. calling addTransceiver).


On Thu, Jan 31, 2019 at 12:48 AM Henrik Boström <hbos@google.com> wrote:

>
>
> On Thu, Jan 31, 2019 at 9:45 AM Henrik Boström <hbos@google.com> wrote:
>
>> 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.
>>
>
> (...but you can always inactive the other layers for a similar effect.)
>
>
>>
>> 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?
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>>