To not change current behavior of the setParameters() method, I would be in favor of a transponder.reset() with the same parameters as addTranscoder() that restarts the transcoder with the new parameters via a renegotiation. On 30/01/2019 15:52, Henrik Boström wrote: > 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 > <mailto: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? > > > > > >Received on Wednesday, 30 January 2019 15:09:09 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:46 UTC