- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Mon, 28 Jan 2019 17:29:25 +0100
- To: WebRTC WG <public-webrtc@w3.org>
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? -- Iñaki Baz Castillo <ibc@aliax.net>
Received on Monday, 28 January 2019 16:30:01 UTC