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

Re: [webrtc-stats] When are "fractionLost", "packetsLost, " "jitter", and other RFC3550-based stats updated?

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Mon, 29 Jan 2018 23:19:01 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-361421124-1517267940-sysbot+gh@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

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