- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Fri, 07 Jul 2017 12:23:37 +0000
- To: public-webrtc-logs@w3.org
>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 delay we can calculate only for the frames, which passed > through to the other side. Interframe delay will account for lots of lost frames > due to some death feedback loops, like we had for screenshare. Lost frames due to network problems might be covered by existing metrics? There's [RTCMediaStreamTrackStats.partialFramesLost](http://rawgit.com/w3c/webrtc-stats/master/webrtc-stats.html#dom-rtcmediastreamtrackstats-partialframeslost), fullFramesLost. There are also packet lost counters and [RTCInboundRTPStreamStats.lastPacketReceivedTimestamp](http://rawgit.com/w3c/webrtc-stats/master/webrtc-stats.html#dom-rtcinboundrtpstreamstats-lastpacketreceivedtimestamp). Not sure about detecting freezes in video, but I believe that should be covered by [RTCMediaStreamTrackStats.estimatedPlayoutTimestamp](http://rawgit.com/w3c/webrtc-stats/master/webrtc-stats.html#dom-rtcmediastreamtrackstats-estimatedplayouttimestamp) if updated to stop increasing when video is frozen (#222). That's only if you poll it frequently through. This proposed metric would steadily increase for jittery video with repeatedly small lags that might not be detected if you poll for last played out sample. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/229#issuecomment-313666890 using your GitHub account
Received on Friday, 7 July 2017 12:23:43 UTC