1330575 - jitter is not accurate in webrtc getStats report

Status: RESOLVED WORKSFORME

(Core :: WebRTC: Networking, defect)

Description

[shuquan825]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Steps to reproduce:

1. make a video call using Firefox50
2. monitor audio/video jitter in webrtc getStats report 


Actual results:

the value is very big sometimes, we use the following way to get jitter, is it ok? Btw, is jitter measured by second?

inbound: report[inbound_rtp_audio].jitter * 1000
outbound: stats[report[outbound_rtp_audio].remoteId].jitter * 1000

when we limit bandwidth to a certain value, we will get jitter value like the following. and at the same network situation, Chrome will return less than 100 in most time. And at this time point, the video quality is good enough.

1059.2
1460.2
28551.9
1176.1
13349.7

Comment 1

[Byron Campen [:bwc]]

The way we get the jitter stats seems pretty straightforward to me, and I certainly hope that a difference as large as this would not be due to changes in webrtc.org code. Seems like maybe we're seeing artifacts due to the different networking implementation? jesup?

Comment 2

[kaili]

We also meet the same issue. The jitter get from getStats() in Firefox can be 0.1~10+, which is far different from the jitterBufferDelayMS(about 10~500ms) in Chrome. Could somone help to let me know what the meaning of jitter, or how do you get the jitter value in Firefox? Thx!

Comment 3

[Nico Grunbaum [:ng, @chew:mozilla.org]]

(In reply to shuquan825 from comment #0)
> the value is very big sometimes, we use the following way to get jitter, is
> it ok? Btw, is jitter measured by second?
You are correct, jitter is measured in seconds. See: https://w3c.github.io/webrtc-stats/#inboundrtpstats-dict*

Comment 4

[Byron Campen [:bwc]]

So, is this working as intended?

Comment 5

[Nico Grunbaum [:ng, @chew:mozilla.org]]

I think this was working as intended. I have done a few tests and the stats looks correct for video, but they are always zero for audio. I have filed a separate issue for that, bug 1525341.