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

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