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

WebRTC Statistics Specification

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...

WebRTC Metrics