search

w3c / webrtc-provisional-stats

https://w3c.github.io/webrtc-provisional-stats/
Other
6 stars 11 forks source link

Relative packet arrival delay #13

Open jakobivarsson opened 5 years ago

jakobivarsson commented 5 years ago

We would like to add two new audio receiver network metrics called relativePacketArrivalDelay and totalPacketsReceived.

relativePacketArrivalDelay measures the difference between the expected arrival time (based on the packets we have seen so far) and the actual arrival time in milliseconds as a cumulative count. The metric can be used to identify networks that are “hard” for the jitter buffer (causing jitter buffer underruns) and therefore also networks that will result in “bad” audio quality. RTP jitter metric does not capture network delays properly since it only measures packet inter-arrival times. High jitter or RTT does not mean that we have a lot of loss concealment.

Since relativePacketArrivalDelay is a cumulative metric in ms, we also need another metric as the denominator to calculate the average relativePacketArrivalDelay. We suggest to add totalPacketsReceived for this purpose. I know there is an RTP packetsReceived metric, but I’m unsure if there might be differences between the number of packets received by the jitter buffer and the number of packets received from the RTP stream.

henbos commented 5 years ago

packetsReceived are on the inbound-rtp stats and jitterBufferDelay and friends are on the track/receiver stats. Which I think should represent the same thing in the case of receiving, it's a big confusing to have RTP stats and track/receiver stats in separate dictionaries.

jakobivarsson commented 5 years ago

Yes, I agree that it is a bit confusing. However, after some investigation, I think it should be good enough to use packetsReceived.