- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Thu, 18 Aug 2022 15:05:30 +0000
- To: public-webrtc-logs@w3.org
I don't think sender/receiver/transceiver objects add enough information to justify adding more objects to the stats report, so I propose we don't add them back to webrtc-stats 1.0. If people are OK with that then the only remaining questions is when to create and destroy the RTP stats objects. Regarding creation: - Proposal 1.A: Delay creation of inbound-rtp until after the SSRC is known. In the case of unsignalled SSRC this means delaying it until after the first packet is received, which means some WPTs need to be updated to stop assuming SSRC is signalled. - Proposal 1.B: Having inbound-rtp conditioned on whether or not the SSRC is known adds an unnecessary dependency on SSRC signalling, let's instead create it when the receiver is configured to receive a stream. The mid is known even if the ssrc isn't. WPTs don't need to be updated. Regarding destruction: - Proposal 2.A: Never delete RTP stats objects ensuring the sum of packet counters always go up. Each new SSRC used is a memory leak and browsers need to implement caching on removal. - Proposal 2.B: When a configuration changes which RTP streams exist, delete old RTP stats objects. This means getStats only provides a snapshot containing current RTP streams. Easy to implement and no leak, but the app does not have the full picture. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/643#issuecomment-1219607475 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 18 August 2022 15:05:32 UTC