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

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

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Wed, 07 Jun 2017 02:02:19 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-306664580-1496800937-sysbot+gh@w3.org>
@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](

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:21:39 UTC