W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2018

Re: [webrtc-stats] Missing definition of "deleted". When exactly do stats get deleted?

From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
Date: Thu, 18 Jan 2018 08:55:55 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-358579908-1516265754-sysbot+gh@w3.org>
In many cases, the answer will be obvious; in other cases not so much. I think it needs answering for both event-emitting and getCompletedStats cases, and agree that it's not defined clearly now.

1. replaceTrack and removeTrack destroys the binding between the old track and the sender (it's the binding that is tracked by the stat, not the track), which is the end of that "object". I'm not sure the binding can be unbound by any other means - the language about the track stopping describes not sending anything any more, it doesn't say that it gets detached.
2. A stream stat would be destroyed when it's no longer of interest - when it's no longer listed as a stream on any of the incoming or outgoing tracks.
3. transceiver.stop() doesn't destroy anything. In the current API model, transceivers never die.
4. iceRestart should destroy candidate information. For local candidates (which presumably remain stable) I'm not sure if they survive or if the PC gets new candidates with the same value.
5. pc.close() stops all tracks. But the transceivers (and everything related to them) remain in place so that they can be inspected after the stop. I could argue that pc.close() detaches tracks, but I'm not even sure about that.


-- 
GitHub Notification of comment by alvestrand
Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/300#issuecomment-358579908 using your GitHub account
Received on Thursday, 18 January 2018 08:55:57 UTC

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