W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > May 2017

Re: [webrtc-pc] Remove paragraph about removeTrack causing track to be ended remotely.

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Fri, 05 May 2017 18:13:25 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-299537063-1494008004-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:40 UTC