← Back to Knowledge Base

WebRTC Metrics

A comprehensive overview of WebRTC statistics, derived indicators, and observable signals, to better understand call quality, connectivity, and user experience in rtcStats

Back
outbound-rtpoutboundvideo

qualityLimitationDurations

The total time, in seconds, that this stream has spent in each quality limitation state.

Description

Object {"bandwidth"|"cpu"|"other"|"none": number}

MUST NOT exist for audio (this is video only).

A record of the total time, in seconds, that this stream has spent in each quality limitation state. The record includes a mapping for all RTCQualityLimitationReason types ("none", "cpu", "bandwidth", "other").

The sum of all entries minus qualityLimitationDurations["none"] gives the total time that the stream has been limited.

Interpreting Values

As a rule of thumb:

Condition Description
"none" >95% of call time Healthy. The encoder is running without constraints
"none" 80-95% Mild limitations. Brief dips during network transitions or CPU spikes are normal
"none" <80% Significant quality degradation is occurring for a large portion of the call
  • A few seconds of "bandwidth" during call start or network transitions is expected and not a concern
  • Persistent "cpu" limitation means the device genuinely cannot handle the encoding workload. Often it indicates a faulty WebRTC implementation
  • Any sustained limitation means receivers are getting degraded video quality and likely the application itself not doing anything to try and solve the issue

Common Causes

  • "cpu" - Underpowered device (low-end laptop, older phone), high resolution configured beyond what the hardware can encode, complex codec (e.g., H.264 software encoding vs hardware-accelerated), other apps consuming CPU, too many simultaneous encoded streams in group calls
  • "bandwidth" - Network congestion, limited upload bandwidth, WiFi interference or contention, competing upload traffic
  • "other" - Typically both CPU and bandwidth constraints are active simultaneously. We haven't seen this reported (yet)

User Experience Impact

  • The SENDER's video quality drops for ALL receivers in the call
  • Lower resolution - video becomes blurry or pixelated
  • Lower frame rate - motion appears choppy
  • More compression artifacts - blocky regions, especially during movement
  • Receivers have no control over this - it is entirely determined by the sender's device and network

Troubleshooting

  • For "cpu" limitation:
    • Reduce the configured send resolution (e.g., 720p instead of 1080p)
    • Switch to a hardware-accelerated codec if available (check encoderImplementation) or a different codec entirely
    • Close other CPU-intensive apps (video editing, gaming, compiling)
    • In group calls, reduce the number of simultaneously encoded streams (simulcast layers) as well as the number of simultaneously decoded streams
  • For "bandwidth" limitation:
    • Check availableOutgoingBitrate to see the actual bandwidth estimate
    • Reduce competing network traffic (cloud sync, downloads, other tabs)
    • Switch from WiFi to a wired connection if possible
    • Lower the configured maximum bitrate to match realistic network capacity

See also

Notes

  • In general, our preference is for "none" to be the resulting value at all times
  • Too much "cpu" time means the CPU was too busy and the encoder had to limit the bitrate it produces in order to work properly
  • Too much "bandwidth" time means that the network was constrained and while we wanted to send a higher video bitrate (=better media quality), we had to limit ourselves to a lower bitrate due to the network condition
  • "other" usually means that both "cpu" and "bandwidth" had an issue...