Get RTT from `SendSideBWE` about interceptor HOT 5 CLOSED

I'm sorry I broke this for you. I am fine with adding the field back for now, but I would strongly encourage using SR and RR and the new GetStats interceptor instead. The RTT measurements in the GetStats interceptor will be more precise and may, at some point in the future, be used in this interceptor too, when they are available (depends on SR/RR).

In general, I think the GetStats method of the BandwidthEstimator interface was a mistake and should be removed in the future. It is very unclear what a bandwidth estimator should expose via that method, and there's no defined API for how to expose things. The reason I added it was for debugging purposes, but that can be done in better ways and exposing the internal state of the congestion controller (which can change anytime) to production systems seems dangerous.

from interceptor.

hi @mengelbart I am playing with the current GetStats API with BandwidthEstimator to get a sense on my video delay/lagging issue. Glad to spot on this discussion and know that this API is subject to change in future. But anyhow I would like to know, for the state of the art, how should I interpret the stats exposed?

Specifically, would you please kindly shed some lights on the meaning of those stats? Thanks in advance. I see that the stats mainly come from arrival/departure time subtraction but they why divided by 1000.0 ?

"delayMeasurement":   float64(e.latestStats.Measurement.Microseconds()) / 1000.0,
"delayEstimate":      float64(e.latestStats.Estimate.Microseconds()) / 1000.0,
"delayThreshold":     float64(e.latestStats.Threshold.Microseconds()) / 1000.0,
"rtt":                float64(e.latestStats.RTT.Microseconds()) / 1000.0,

from interceptor.

hi @mengelbart I am playing with the current GetStats API with BandwidthEstimator to get a sense on my video delay/lagging issue. Glad to spot on this discussion and know that this API is subject to change in future. But anyhow I would like to know, for the state of the art, how should I interpret the stats exposed?

Specifically, would you please kindly shed some lights on the meaning of those stats? Thanks in advance. I see that the stats mainly come from arrival/departure time subtraction but they why divided by 1000.0 ?

"delayMeasurement":   float64(e.latestStats.Measurement.Microseconds()) / 1000.0,
"delayEstimate":      float64(e.latestStats.Estimate.Microseconds()) / 1000.0,
"delayThreshold":     float64(e.latestStats.Threshold.Microseconds()) / 1000.0,
"rtt":                float64(e.latestStats.RTT.Microseconds()) / 1000.0,

Oh my bad, that conversion is just as simple as to return durations in Milliseconds ?

from interceptor.

Besides, I noticed a strange thing for me in my testing, I use tc with netem to add delay to my RTP packets. And then I observed following stats.

This is without tc delay.

{"averageLoss":2.447401524484472e-239,"delayEstimate":0.156,"delayMeasurement":0.254,"delayTargetBitrate":50000000,"delayThreshold":55.5,"lossTargetBitrate":50000000,"rtt":25.54,"state":"increase","usage":"normal"}

This is with tc delay 40ms + 20ms jitter.

{"averageLoss":0.17790749903923042,"delayEstimate":17.751,"delayMeasurement":2.318,"delayTargetBitrate":1822368,"delayThreshold":59.5,"lossTargetBitrate":100000,"rtt":2.19,"state":"increase","usage":"normal"}

What strikes me most is the rtt here, when I have delay in RTP, the rtt seems really small. And the second thing is that the delay seems cause quite a lot Loss which I did not actually expect to see. It should be just slow but no pkt loss no? Or is it related to NACK from receiver side?

from interceptor.

Hi @adityaa30 @mengelbart

I am going to close this. If that is the wrong decision please re-open and we can land this!

Going forward the stats interceptor is the best place to get all metadata around the quality of the WebRTC connection. If we add this rtt field it might confuse users who look at this value incorrectly.

Really sorry about the breakage @adityaa30 and thanks for contributing :)

from interceptor.