webrtc-stats
webrtc-stats copied to clipboard
w3c
WebRTC Statistics
As more and more offices are adopting open work places, it is important to measure the background noise in open office environments and measure the effect on real-time communication. Is...
It would be good to add receiver stats on how much/often FEC/RED data is received but not needed (since the data they try to protect are received)
perResolutionFramesSent/Received gives the frame counters for each resolution distributionOfTimeSinceLastFrameSent/Received gives the amount of time between frames, so these counters would correspond to appropriate time values for the frame rates, for...
This has been on the plan for a while, but it's nice to have a bug on it.
"outbound-rtp" is now said to cover both RTP and RTX stats. This makes sense because RTP and RTX streams map 1:1 so there is no ambiguity there. In the implementation...
The spec is not particularly explicit as to when a given stats starts being reported. There is a mention of "created" for `MediaSourceStats` and `RTCRtpTransceiverStats`, but none of the other...
we have [reportsReceived](https://w3c.github.io/webrtc-stats/#dom-rtcremoteinboundrtpstreamstats-reportsreceived) and [reportsSent](https://w3c.github.io/webrtc-stats/#dom-rtcremoteoutboundrtpstreamstats-reportssent) but those are the only ones that describe low level rtcp overhead. Defining the number of packets sent is quite complex (how does a compound...
These used to exist on the "track" stats and currently remain on the handler stats (a.k.a. "sender" and "receiver"). Decide whether they should remain here or if we want to...
Make sure that the metrics do not have wrap around issues when copying metrics from RTCP SR and RR fields.
webrtc.org uses either all-padding packets (when RTX is not negotiated) or RTX packets as a way to probe the bandwidth. Prior to Chrome fixing [this issue](https://bugs.chromium.org/p/webrtc/issues/detail?id=10525) at least the padding...