webrtc-stats
webrtc-stats copied to clipboard
w3c
Stat for likelihood of echo
The non-standardized Chromium getStats contains the following stat:
// An instantaneous measurement of the likelihood that there is echo.
// This is a send side stat with range 0 (no echo) to 1 (definitely echo).
// A value of 0.5 (may need updating) indicates very likely echo.
ssrc.googResidualEchoLikelihood
Should we standardize this? double residualEchoLikelihood in RTCMediaStreamTrackStats?
I think this is a useful feature, so it makes sense to standardize it. I'm not aware of any relevant standards related to echo detection.
Do you know if Chromium's implementation was based on something we can reference?
I think it should be left up to the user agent how to determine a likehood but providing an estimate is highly useful to the application.
A stat for maximum value of the last 10s like Chrome has it with googResidualEchoLikelihoodRecentMax is even more useful (as one can hook it up to the UI directly) but I don't think that should be standardized as it is hard to agree on a interval measured. It seems fairly trivial to compute from the instantaneous values.
"Likelihood of echo" has a similar problem to that of rates - it's a snapshot. "Over the last 10s" is useful but 10s is arbitrary. With using counters instead of rates the caller can decide which time span to look at - is there something analogous for likelihoods?
Can we have a residualEchoLikelihoodCounter that increases at a rate of the likelihood of echo?
That is, if the average likelihood of echo is 50% over a 4 second window, the counter will increase by 2.0. The rate calculated is 0.5/s.
I don't think the user agent implementation even needs to be able to calculate likelihood of echo as a percentage. It's enough if the user agent is able to estimate whether or not there is echo. Even with a boolean true false, the rate could be 0 or 1.
Perhaps the only requirement should be that for any period of time there is echo detected by the user agent, the average increase in the echo counter should be at a rate [0.5, 1], and for any period of time there is not echo detected by the user agent the rate should be [0, 0.5).
Since echo detection is not perfect I think it should remain a likelihood, not a counter.
How about the UA returning and indicator whether there was echo since the last getStats call? The browser can update its internal estimate at its own pace if it returns the maximum likelihood. If you call getStats only once every 10s you get the same as googResidualEchoLikelihoodRecentMax.
(in reality its a bit more tricky since you are unlikely to call getStats only for that purpose)
I'm afraid the API is designed such that a caller should not need to know about other getStats-callers. Any "since last call to getStats" logic means invoking getStats affects all other callers.
(Maybe residualEchoLikelihoodIntegral is a better name for residualEchoLikelihoodCounter.)
About the counter idea: it is typically the maximum echo likelihood in a time interval that's the most interesting to track, not the average (which is what you would get from the counter).
This is why I implemented the max from the last 10 seconds, which is admittedly a compromise, but I couldn't think of a better way to do it.
On Tue, Feb 14, 2017 at 4:15 PM, henbos [email protected] wrote:
I'm afraid the API is designed such that a caller should not need to know about other getStats-callers. Any "since last call to getStats" logic means invoking getStats affects all other callers.
(Maybe residualEchoLikelihoodIntegral is a better name for residualEchoLikelihoodCounter.)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/webrtc-stats/issues/153#issuecomment-279734896, or mute the thread https://github.com/notifications/unsubscribe-auth/ARGCovOnRpRVd0Wu3EEfqWpg5GcMBA1vks5rccT2gaJpZM4Lz3cL .
This sounds to me like it's an experimental stat. The question is whether we can define something that is useful to put into the stats, without binding ourselves to a specific implementation.
