- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Mon, 29 Jan 2018 23:19:01 +0000
- To: public-webrtc-logs@w3.org
FWIW, Firefox implements live stats for all non-remote stats, from counters in our rtp stack. I believe webrtc.org did as well until around ~57, when we noticed some of the upstream bits we'd been relying on disappeared on us, and we had to work around it. Is that perhaps when Chrome broke? @taylor-b I agree the spec language is problematic, and that we need to clarify it to be live. E.g. [timestamp](http://w3c.github.io/webrtc-pc/#dom-rtcstats-timestamp): *"The timestamp, of type DOMHighResTimeStamp [HIGHRES-TIME], associated with this object. The time is relative to the UNIX epoch (Jan 1, 1970, UTC). For statistics that came from a remote source (e.g., from received RTCP packets), timestamp represents the time at which the information arrived at the local endpoint."* It doesn't explicitly say what the timestamp represents in the non-remote case. It probably should (time of sampling?) Also, the individual stats members of [RTCReceivedRTPStreamStats](https://w3c.github.io/webrtc-stats/#dom-rtcreceivedrtpstreamstats) - like e.g. `packetsLost` - are reused in both [RTCInboundRTPStreamStats](https://w3c.github.io/webrtc-stats/#dom-rtcinboundrtpstreamstats) and [RTCRemoteInboundRTPStreamStats](https://w3c.github.io/webrtc-stats/#dom-rtcremoteinboundrtpstreamstats), yet their prose seems to only cover use in the latter. Ditto for [RTCSentRTPStreamStats](https://w3c.github.io/webrtc-stats/#dom-rtcsentrtpstreamstats) and its two derivatives. We should update that prose. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/313#issuecomment-361421124 using your GitHub account
Received on Monday, 29 January 2018 23:21:17 UTC