Skip to main content

Stats and Metrics

The Webcaster API provides two types of Quality Of Service reporting mechanisms:

  • Client side statistics
  • Collection of backend metrics


In order to display client side statistics that are visible directly in your Webcaster application, please:


Please find a list of available stats here. Also note that most of the stats are available in Chrome. The other browsers, e.g. Firefox, may not provide all the documented stats.

Stats Example

The following snippet will enable stats reporting on the client side:

// rtcUser: instance of RtcUser

rtcUser.on('ReceivedWebRTCStats', function(event) {
var results =;

Ingest Quality Indicators

Bad network is the major reason for bad end to end user experience. In case of bad network conditions you can warn your users and they will be able to take further steps in order to improve the situation.

There are specific stats that indicate the current upstream quality:

  • roundTripTime - Current time in milliseconds that data takes from the client to the webcaster server and back.
  • packetLoss - Percentage of packets lost during past 10 seconds.
  • videoSendDelay (Chromium based browsers only) - Delay before video frames are send to the server.

Those statitics will allow you to show a traffic light to your webcasters, that indicates the current ingest quality. This regards the upstream network conditions from your customers browsers to our webcast servers.

Traffic Light Recommendations

Based upon our analysis, we have gathered recommendations for indicating bad streaming conditions to the end users.

Round Trip Time

We concider an rtt of 150 or less as acceptable. We observed RTT values going up to 150, with still good playback experience. Above 150 and below 250 the viewer experience will degrade slighly. Above 250 milliseconds users should check their network and see if there are things that can be improved.

Packet Loss

A packet loss of less than 5% still results good playback experience. Greater than 10% of lost packages will degrade viewer experience, especially for streams with higher bitrates (2Mb and above). Above 10% of packet loss, we observed that streams can get chunky and your users should take action then.

Sample for a simple traffic light implementation:

// rtcUser: instance of RtcUser

rtcUser.on('ReceivedWebRTCStats', function(event) {

var results =;
var roundTripTime = results.roundTripTime;
var packetLoss = results.packetLoss;

if (!roundTripTime || !packetLoss) return; // values can be undefined

// thresholds
var quality = 'good';
var packetLossLowerBound = 5;
var packetLossUpperBound = 10;
var rttLowerBound = 150;
var rttUpperBound = 250;

if(packetLoss < packetLossLowerBound && roundTripTime < rttLowerBound) {
quality = 'good';

if ((packetLoss > packetLossLowerBound && packetLoss < packetLossUpperBound)
|| (roundTripTime > rttLowerBound && roundTripTime < rttUpperBound)) {
quality = 'medium';

if (packetLoss > packetLossUpperBound || roundTripTime > rttUpperBound) {
quality = 'bad';

console.log('roundTripTime: ', roundTripTime);
console.log('packetLoss: ', packetLoss);
console.log('quality: ', quality);



Sending metrics to our backend will help us analyze your customers webcast ingest quality and track down client side issues. Additionally you will be able to see useful information in the Analytics Dashboard. Please refer to the nanoStream Cloud documentation for details on how to enable client metrics for your organization.

Metrics configuration

In order to enable sending metrics from the clients, please configure your accountId and accountKey with the setConfig() API call.

// rtcUser: instance of RtcUser
var rtcConfig = {
metrics: {
accountId: 'myAccountId',
accountKey: 'myAccountKey'

// Set metrics credentials