henbos

@alvestrand Do you have an opinion how to phrase this so that it is an approximation? We want vagueness but it shouldn't be completely untestable

Makes sense to me

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...

We got rid of "sender", "receiver", "transceiver" and "track" stats in favor of just moving everything to "outbound-rtp" and "inbound-rtp" which we've already done in both spec and implementation so...

I filed https://crbug.com/1368987 regarding beefier WPTs.

From https://codereview.webrtc.org/2965033002/ about usage case of this stat: > We need it to measure lags on screenshare. In some sense, this metric is better > than e2e delay - e2e...

@ksridhar lastPacketReceivedTimestamp was added in Chrome 75.0.3767.0 and is comparable to timestamp, both of which you can construct Date objects from, and should be easily comparable to current time.

Sorry I just inspected lastPacketReceivedTimestamp on tip-of-tree and while it does increase correctly (goes up by one every second as long as it is receiving packets), it has a different...

[RTCRtpReceiver.getSynchronizationSources](https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver-getsynchronizationsources) exposes not only [timestamp](https://w3c.github.io/webrtc-pc/#dom-rtcrtpcontributingsource-timestamp) but [rtpTimestamp](https://w3c.github.io/webrtc-pc/#dom-rtcrtpcontributingsource-rtptimestamp). Unlike getStats(), this API can be polled frequently without performance concerns. The rtpTimestamp is a recent addition, it first appears in Chrome 76.0.3806.0.

Thanks I filed [an issue](https://github.com/w3c/webrtc-pc/issues/2281)!