Closed Bug 1154807 Opened 10 years ago Closed 10 years ago

WebRTC getStats - some stats seem to often be incorrect.

Categories

(Core :: WebRTC, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1161079

People

(Reporter: ehugg, Unassigned)

Details

We have a report from the Spark team that while bytes/packetsSent and bytes/packetsReceived seem reliable, other stats like packetsLost, bitrateMean, droppedFrames, mozRtt, jitter are often wrong. The team has been trying to use these values to determine when the call is it trouble and they will see packetsLost at 0 and bitrateMean at 1MB even whene the video is frozen for example. I did some testing around packetsLost and found that it will stay at zero when the stream stops and not be updated until a few seconds after the stream resumes. Not sure if that's easily fixable since we don't know they're lost and not just late until we receive packets later in the stream.
What do you mean "when the stream stops"? How do you stop it and on what end? What's purportedly wrong with droppedFrames, mozRtt and jitter? and how often is often? STR? FWIW here's a local test script I use: attachment 8582572 [details] (could have sworn I had a newer one with mozRtt but can't find it).
For my tests I made a version of FF that drops the packets on the sender side in rtp_sender.cc. Thanks for your local test script I will try that out and see what it does.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.