W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > February 2020

Re: [webrtc-stats] End-to-end delay metrics (#537)

From: henbos via GitHub <sysbot+gh@w3.org>
Date: Mon, 10 Feb 2020 10:35:23 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-584058163-1581330921-sysbot+gh@w3.org>
I think JS can calculate the "estimatedNtpDelta" this using RTCRemoteInboundRtpStreamStats.roundTripTime (or totalRoundTripTime/rotalRoundTripTimeMeasurements), RTCRemoteOutboundRtpStreamStats.remoteTimestamp and RTCRemoteOutboundRtpStreamStats.timestamp. Chrome would need new metrics and some bug fixes for this to fly.

playoutTimeInReceiverNtp should be RTCInboundRtpStreamStats.timestamp if getStats uses the NTP clock. (Chrome may have wrong offset here in current implementation?)

estimatedPlayoutTimestamp is the timestamp in the sender NTP, though it assumes RTCP with RTP->NTP mapping, which wouldn't be reliable if the server uses contributing sources. But separating NTP delta and capture timestamp in separate metrics is good, because then we can use the same math if we get a better capture timestamp in the future through header extensions.

GitHub Notification of comment by henbos
Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/537#issuecomment-584058163 using your GitHub account
Received on Monday, 10 February 2020 10:35:26 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:50 UTC