- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Jul 2017 09:22:27 +0000
- To: public-webrtc-logs@w3.org
Is there an update on this? Now that `ended` doesn't fire anymore, is there no event one can listen to as a result of the other side doing removeTrack? The only event we have is `track` event being fired for added tracks [according to remote track processing](https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#process-remote-track)? > 4. Queue a task to fire an event named track with transceiver, track, and streams at the connection object. This only happens if the event has not fired for the track before according to [the set remote description steps](https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#set-description). > 6. If the direction of the media description is sendrecv or sendonly, and transceiver.receiver.track has not yet been fired in a track event, process the remote track for the media description, given transceiver. I hope we can't re-use a transceiver with an old track whose event will not fire because it has already been fired before. Assuming [remote streams should not be created for stream-less local tracks](https://bugs.chromium.org/p/webrtc/issues/detail?id=7933), the `trackremoved` event should fire on the peer connection and not on individual streams. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1161#issuecomment-313049949 using your GitHub account
Received on Wednesday, 5 July 2017 09:22:33 UTC