- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Fri, 17 Jun 2022 09:46:59 +0000
- To: public-webrtc-logs@w3.org
To clarify, I said that we shouldn't invalidate the cache every time a packet counter increments since that would make caching rarely applicable. But if receiving the first packet causes a new stats object to appear then we should definitely invalidate the cache. Regarding this spec issue, the core of the issue appears to be the assumption that we need the SSRC in order to create the RTP stats objects. And when this spec issue was filed I think that was true. As of recently though we've added the mid and rid properties though, so it would be possible to create these objects at signalling time even if the SSRC isn't known, which may be more consistent with what Chromium implementations currently do. There would still be the issue about "well what if the ssrc changes?". The spec seems to think that RTP objects are permanent, so a new SSRC should imply a new RTP object and the old one remains. But at least in the Chromium implementation, we don't do this... the RTP stats objects exposed are just what the streams are currently, and if the SSRC goes away then so does the stats object. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/619#issuecomment-1158702487 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 17 June 2022 09:47:01 UTC