Closed
Bug 1154807
Opened 10 years ago
Closed 10 years ago
WebRTC getStats - some stats seem to often be incorrect.
Categories
(Core :: WebRTC, defect)
Core
WebRTC
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.
Comment 1•10 years ago
|
||
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).
Reporter | ||
Comment 2•10 years ago
|
||
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.
Reporter | ||
Updated•10 years ago
|
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.
Description
•