- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Tue, 17 Jul 2018 14:50:58 +0000
- To: public-webrtc-logs@w3.org
replaceTrack() does not require re-negotiation, but setStream() does. But setStreams() was added to complement replaceTrack(), meaning the use-case that was in mind was to do both things, but doing both things would mean half of the operation happens immediately and the other half happens after an exchange. This seems awkward? This now may lead to more events and complexity. What's the compelling use case for changing streams? If we truly want to repurpose a transceiver with a renegotiation (same thing as adding a new transceiver except we are done with the old usage and don't want to waste m= sections) then this might be achievable with an setter-API that on the other endpoint ends up with processing the removal of the old stuff and then firing another ontrack with the same transceiver but the new track and streams. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1937#issuecomment-405610169 using your GitHub account
Received on Tuesday, 17 July 2018 14:51:01 UTC