Back to Blog

WebRTC, Compute Pressure and rtcstats

Compute Pressure is the browser's privacy-preserving CPU load signal. Here's what it means, how to use it, and how rtcstats-js already collects it side-by-side with your other WebRTC metrics.

Posted by

WebRTC, Compute Pressure and rtcstats

Understanding, measuring and monitoring the CPU state of a device in a WebRTC session is important for media quality.

Today there are several ways to measure CPU state in WebRTC. You can:

And then there's using the new Compute Pressure API in Chrome. Hopefully, other browsers will follow (at their own snail pace).

What's Compute Pressure?

Compute Pressure is the browser's way of telling you the CPU might be overloaded without giving away too much information.

You won't get from it a percentage of load on the CPU, but rather a broader "nominal", "fair", "serious" or "critical" indication.

The reason for lack of granularity is maintaining the user's privacy. Knowing how the CPU acts at a lower level may enable services to identify specific devices of users.

More on this can be found in the WebRTC Glossary.

What do you do with it?

Here's my 2 cents at the moment about it:

  • If you're "normal", then you can bump up your bitrate and splurge on the machine's CPU
  • If you're "fair", then you're most likely striking the correct balance of features and CPU performance
  • If you're "serious" about it, then it is time to think about optimization and reduction in capabilities
  • Got to "critical"? Time to take real steps to reduce that load on the CPU

That's easier said than done.

I'll split it into two domains of things you need to do:

  • On the client-side, track the value if you can. Don't stay in the realm of "serious" for too long. Be drastic in your measures if you hit "critical"
  • On the server-side, collect this data. It will be golden for troubleshooting. For long term maintenance and ongoing optimizations, check what's your average value for the service. You can decide to split it by device types while at it

rtcStats and Compute Pressure

Lucky for you, we're on top of things - that's the benefit of having Philipp AND Olivier in your corner when delving into WebRTC-specific projects… 😎

rtcstats-js (2.2.2 or higher) already integrates it with getStats, so assuming you run on a browser supporting Compute Pressure (think… Chrome) - you simply get an additional time series with the data and you can look at it side-by-side with all the other time series. For a test we used one of the WebRTC samples and started with setting the resolution to 1080p after the initial ramp-up to 640x480 - with VP8 that is already a challenge for the CPU. That showed a first dip in the compute pressure results (which we map to a 3 colors traffic light system and show as a color bar at the top of the graph), marked by the (1)

rtcStats showing compute pressure dip on resolution ramp-up to 1080p

WebRTC quickly adapted and the CPU got back to nominal state. So to make things a little more challenging we decided to start compiling libWebRTC from scratch which is greedily using all the CPU power it can get. The result of that was an immediate drop in the compute pressure value - see (2) - while WebRTC struggled to adapt to the higher per-frame encode times by dropping frames - see (3). Resolution dropped gradually from 1080p during this too.

Compute pressure drops and frame drops while libWebRTC compiles in the background

For even more fun you can see two phases where the compilation was interrupted. WebRTC had already stopped attempting to encode 1080p at those points so dealt with the situation a bit better than before.

This even affected the capture frame rate as one can see in this graph:

Capture frame rate during the compute pressure test

Understanding how the media pipeline reacts under load, in particular external load is quite interesting and one needs to look at a lot of different metrics (resolution, frame rate, encode time, quality limitation reason) in parallel. Compute pressure is another signal here which we think fits nicely into the timeseries and the rtcstats.com graphs you already love.

We're going to figure out some Observations as well as better root cause analysis using this new metric moving forward. We also plan on integrating the experimental new cpuPerformance API which gives an upfront estimate of how powerful the CPU is once it is generally available.

👉 If you're not collecting all WebRTC metrics for observability purposes, then you're doin' it wrong. Contact us and we'll help you figuring out your next steps for better WebRTC quality