- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Tue, 09 May 2017 16:10:06 +0000
- To: public-webrtc-logs@w3.org
> We're also missing a step that will remove the track from any remote streams that were created for it in this step: https://www.w3.org/TR/webrtc/#process-remote-track Agreed. I decided to test Chrome and Firefox behavior here using https://jsfiddle.net/jib1/xrwsp7o9/ The good news is that, where available, `removeTrack/removeStream` followed by `addTrack/addStream` works reliably in both browsers to replace content, over and over. * Both browsers fire `ended` on remote tracks. * Both browsers fire `removestream` on pc2. But there were differences in the details that threw me: * Only Firefox fires `addtrack` on the remote stream on adding the second track (likely a limitation of the adapter.js ontrack polyfill, since with addStream the stream comes pre-populated). * But neither browser fires `addTrack` on the existing remote stream on subsequent renegotiation. * Only Chrome fires `removetrack` on the remote stream. * Firefox leaves old tracks in the remote stream until a subsequent renegotiation adds tracks to it! I almost missed the good news because of the last one. I'd say the last three here are bugs. > I don't know if this was intentional or just an oversight from the RTCRtpTransceiver refactoring. I think it's important to support this model, for legacy reasons if nothing else, to let users `pc.removeTrack(sender); pc.addTrack(newTrack, sameStream);` and have the remote stream still be playable in a video element. - If we switch to not cleaning up the remote streams anymore, then it'll accumulate ended/muted tracks, which seems undesirable, and might break existing use, causing the video element to not play etc. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1161#issuecomment-300215486 using your GitHub account
Received on Tuesday, 9 May 2017 16:10:12 UTC