Closed
Bug 976669
Opened 11 years ago
Closed 5 years ago
about:webrtc should show running kbps speeds each stream (and auto-update)
Categories
(Core :: WebRTC, defect, P3)
Tracking
()
RESOLVED
FIXED
mozilla80
Tracking | Status | |
---|---|---|
firefox80 | --- | fixed |
backlog | webrtc/webaudio+ |
People
(Reporter: jib, Assigned: dminor)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
Some feedback in Bug 904622 suggests that our current about:webrtc page, which does not auto-update nor show kbps speeds for each stream, should do those things.
Useres are comparing it to chrome://webrtc-internals, and I think there are two components to that:
1) More information and live updating information (this bug)
2) Nice graphs.
In particular, send and receive rates may be calculated today from existing stats over time, like the attached page shows.
One solution would be to crib from the attachment, if it is fast enough. If not, (or if we decided not to auto-update for some reason) we could look at calculating speeds internally.
Comment 1•11 years ago
|
||
I should point out that I've tried auto-update, and it can be frustratingly janky. Also, we have to be careful not to wipe out the last-known stats for PCs when we refresh, or it will make diagnosing failed calls a bit difficult.
Reporter | ||
Comment 2•11 years ago
|
||
Have we tried auto-update since your rewrite? Perhaps there's less overhead now.
We'll need to break down what expectations are. For comparison, Google's webrtc-internals page appears to be a pure monitor in that it goes blank once the call ends (or tab closes, I cannot tell with apprtc), with a download button for loggy stuff.
Comment 3•11 years ago
|
||
(In reply to Jan-Ivar Bruaroey [:jib] from comment #2)
> Have we tried auto-update since your rewrite? Perhaps there's less overhead
> now.
>
I have not tried again, no. I would be pretty surprised if the rewrite helps with this in any significant way; we're talking about a pretty small amount of data.
Updated•11 years ago
|
Priority: -- → P2
Target Milestone: --- → mozilla33
Updated•11 years ago
|
Priority: P2 → P3
Updated•11 years ago
|
Target Milestone: mozilla33 → mozilla35
Updated•10 years ago
|
backlog: --- → webRTC+
Rank: 35
Comment 4•7 years ago
|
||
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
Assignee | ||
Updated•5 years ago
|
Assignee: nobody → dminor
Severity: normal → S3
Status: NEW → ASSIGNED
Priority: P4 → P3
Assignee | ||
Comment 5•5 years ago
|
||
Assignee | ||
Comment 6•5 years ago
|
||
This would be improved by smoothing the values a bit, but I'm not sure that is
worth the extra complexity at this point. I left out the remote values because
they do not update regularly, but with smoothing, we might be able to
include them as well.
Depends on D83317
Pushed by dminor@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ead0a7cb8958
Automatically update ICE and RTP stats; r=ng
https://hg.mozilla.org/integration/autoland/rev/532f25e20ffc
Estimate bitrate for local streams; r=ng
Comment 8•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/ead0a7cb8958
https://hg.mozilla.org/mozilla-central/rev/532f25e20ffc
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox80:
--- → fixed
Resolution: --- → FIXED
Target Milestone: mozilla35 → mozilla80
Updated•5 years ago
|
QA Whiteboard: [qa-80b-p2]
You need to log in
before you can comment on or make changes to this bug.
Description
•