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

@taylor-b I did some digging, and I need to correct your initial premise:

> In the pre-transceiver world, we had addStream/removeStream methods, and "addstream"/"removestream" events. ... 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?

The answer [since Oct 2014](https://github.com/w3c/webrtc-pc/pull/3#issue-45833676) has been *"onremovestream has been removed (now, .onended is fired)."* Transceivers weren't added until [a year later](https://github.com/w3c/webrtc-pc/pull/293), and the "ended" language remains to this day (https://github.com/w3c/webrtc-pc/pull/1168).

For a whole year, the spec was `addTrack`/`removeTrack` on one side, and `track` and `ended` on the other, and nothing else. That's the year Firefox [implemented addTrack/removeTrack](
https://hg.mozilla.org/mozilla-central/rev/79525105ef9a).

In other words, we did not go straight from streams to transceivers, and the `removestream` event was not removed because of transceivers. It was removed because of `ended`.

So we moved from:
 1. `addStream`/`removeStream` firing `onaddstream` and `onremovestream` *(Chrome)*, to
 2. `addTrack`/`removeTrack` firing `track` and `ended` *(Firefox)*, to
 3. `addTransceiver`, and confusion about what happens remotely *(Nobody)*.

I cover these 3 stages in my recent [blog post](https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/) and webinar.

Also note Chrome fires `track` and `ended` for both `addStream` and `addTrack` through [adapter.js](https://github.com/webrtc/adapter).

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1161#issuecomment-306664580 using your GitHub account

Received on Wednesday, 7 June 2017 02:02:25 UTC