- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Mar 2019 14:52:23 +0000
- To: public-webrtc-logs@w3.org
getStats() should only return stats for objects that are "live". If the underlying object that the stats represent is removed, "onstatsended" should fire. This should happen to RTP stream stats already, and if that's not explicit then we should file a spec bug. So yes, if a transceiver is stopped I think it follows that we should fire "onstatsended" for the sender/receiver/rtp stats. sender/receiver.getStats() is already defined as "gather stats for all RTP streams that are sent/received by the sender/receiver". Which means this already today, without the proposed change, returns an empty set before you've negotiated, because the [lifetime of RTP stream stats](https://w3c.github.io/webrtc-stats/#the-rtp-statistics-hierarchy) start when the first RTP packet is sent/received. I think this needs to be fixed to include "sender" and "receiver" stats too in the case of calling getStats() before you have RTP streams because that makes more sense, but my point is that this is already a thing. Even if transceiver.stop() doesn't remove the transceiver, it DOES remove the RTP streams. This problem is tangential, and not currently a blocking issue. And no, we should not decide whether or not to keep objects around based on GC. It is based on whether or not they are attached to the PC. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2092#issuecomment-472455634 using your GitHub account
Received on Wednesday, 13 March 2019 14:52:25 UTC