W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > June 2019

[webrtc-stats] Detecting glitches (#443)

From: henbos via GitHub <sysbot+gh@w3.org>
Date: Tue, 11 Jun 2019 15:27:20 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-454757940-1560266838-sysbot+gh@w3.org>
henbos has just created a new issue for https://github.com/w3c/webrtc-stats:

== Detecting glitches ==
Chrome's legacy stats has "googInterframeDelayMax".
This can help detect if any time during the call there was a large delay between frames such as a glitch.

The standard API has stats useful for detecting long freezes, such as by looking at framesPerSecond, framesReceived and lastPacketReceivedTimestamp.

But if a minor freeze/glitch occurs of say 100 ms this might not be noticed by an application that polls getStats() every one or several seconds.

Using framesReceived on a per-second basis, a 100 ms loss of frames would certainly be noticeable, but it would look the same as if the frame rate was slightly reduced; not as bad for the user experience as a glitch.

Should we add a new metric for this? Can it be done without a "max" metric? (Problem with "max" is it says nothing about recent stuff, it speaks of the entire history of the call.)

Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/443 using your GitHub account
Received on Tuesday, 11 June 2019 15:27:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 11 June 2019 15:27:22 UTC