- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Fri, 05 May 2017 18:13:25 +0000
- To: public-webrtc-logs@w3.org
(I deleted earlier comments where I was confused) Doing a sanity recap: In my book we've got 3 fundamentally different versions of this API: 1. streams (addStream/removeStream) (Chrome) 2. tracks (addTrack/removeTrack) (Firefox) 3. transceivers (addTransceiver/removeTransceiver) (Nobody) A difference between `pc.removeTrack(sender); pc.addTrack(withTrack)` and `await sender.replaceTrack(withTrack)` is that the former renegotiates (assuming `pc.onnegotiationneeded` is set up properly) whereas the latter does not. So, with `pc.removeTrack(sender); await wait(10000); pc.addTrack(withTrack)` I think the big difference is that for 10 seconds I'd expect there to be *no track*, not a black track, remotely. Specifically, I'd expect a renegotiation to fire 'ended' on my old track, which would be removed from the peerconnection-managed stream, then 10 seconds later, another renegotiation would trigger a`track` event on my peer connection with my "new" track, now added to the peerconnection-managed stream. This was certainly the expectation before transceivers. Maybe `receiver.track` should be nullable after all? -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/1168#issuecomment-299537063 using your GitHub account
Received on Friday, 5 May 2017 18:13:32 UTC