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

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

Received on Thursday, 31 January 2019 08:17:54 UTC