[webrtc-pc] Do we need a "trackremoved" event?

taylor-b has just created a new issue for https://github.com/w3c/webrtc-pc:

== Do we need a "trackremoved" event? ==
In the pre-transceiver world, we had `addStream`/`removeStream` methods, and `"addstream"`/`"removestream"` events. If you call `addStream`, then do an offer/answer, the `"addstream"` event will fire for the PeerConnection on the other side, and same for `removeStream`/`"removestream"`.

Now, we have `addTrack`/`removeTrack`... But we only have a single event, `"track"`. So how are applications expected to know when the other peer removed the track? They would need to inspect the transceiver and see if its direction changed (for example, from `"sendrecv"` to `"recvonly"`). This makes the migration from the stream-based API (which is still all that Chrome implements) to the track-based API non-trivial.

So, do we need an `"trackremoved"` event that fires when a transceiver's direction loses the "send" bit as a result of setting a remote description? This seems like a pretty trivial addition which would be appreciated by existing application developers.

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

I don't know if this was intentional or just an oversight from the `RTCRtpTransceiver` refactoring.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1161 using your GitHub account

Received on Thursday, 4 May 2017 19:20:59 UTC