Controlling bandwidth usage in WebRTC (and how googSuspendBelowMinBitrate works)

There are cases when we would like to limit the maximum bitrate being transmitted by WebRTC to avoid wasting resources in the user endpoints or save money reducing the bandwidth usage in our servers.   This is because the maximum bitrate by default in Chrome is around 2Mbps and for many use cases a much lower bitrate provides still pretty good quality.   BTW using a lower bitrate can also help with stability of quality in multiparty scenarios by reducing the amount of competition among different streams.

There is no simple API to configure the maximum bitrate in WebRTC (although there is one in ORTC) but there are 3 ways to do this by mangling the SDP.

1. Use the standard b=AS:BITRATE (Chrome) or b=TIAS:BITRATE (Firefox) attributes in the SDP for the audio or video channel[1]
2. Use codec specific attributes (this work at least for opus audio codec with maxaveragebitrate property) [2]
3. Use the proprietary x-max-bitrate attribute in the video channel of the SDP answer.  For example with something like this:

answer.sdp += "a=fmtp:100 x-google-max-bitrate=500\r\n";

My network sucks right now (I blame my neighbors wifis) and the bitrate is not very stable, but you can see how in average it stays under 500kbps.

There are also people interested on changing the minimum bitrate being used (the default is 30kbps in Chrome and increasing it is very dangerous unless you are in a very controlled environment). This can also be done mangling the SDP:

answer.sdp += "a=fmtp:100 x-google-min-bitrate=1000\r\n";

Another requirement is changing the initial bitrate to speed up the initialization and start with a higher bitrate than the default one (300 kbps).   This can also be done mangling the SDP:

answer.sdp += "a=fmtp:100 x-google-start-bitrate=1000\r\n";

In the graph you can see a session where the start bitrate and the minbitrate where set to 1000 kbps.

For the last three years we have seen comments in the mailing lists and issue tracker about something called "suspend below min bitrate" (3).  I was very curious about this feature as you can see in the ticket comments and finally decided to play with it and also  take a look at the code.

The feature is very simple to understand. If you enable it then WebRTC will stop sending video as soon as the bandwidth estimation goes below the minimum bitrate.  Otherwise by default WebRTC insists on sending minBitrate even if it creates congestion in the network.

To enable it you just need to pass an optional proprietary constrain while creating the PeerConnection:

var pc = new RTCPeerConnection({ iceServers: [] }, { optional: [{ "googSuspendBelowMinBitrate": true }] });
With that in place the video stops as soon as you don't have enough bandwidth for the video.  So if the bandwidth estimation is 60kbps and the audio needs 40kbps the video will still be sent until bandwidth estimation is <= 40kbps.

One of the tricky/interesting parts is the algorithm to allocate the bandwidth to different streams (for example for audio y video or for multiple streams in a single peerconnection or for different qualities when using simulcast).  For that there is a class BitrateAllocator ( in Google's webrtc code.

def allocate_bitrates(bitrate):
   sum_max_bitrate = sum(stream.max_bitrate) for stream in streams
   sum_min_bitrate = sum(stream.min_bitrate) for stream in streams
   if bitrate > sum_max_bitrate:    
      # All streams get max_bitrate
   elif bitrate > sum(stream.min_bitrate) for stream in streams:
      # Each stream gets stream.min_bitrate + (bitrate - sum_min_bitrate) / streams.length
      foreach(stream in streams)
         if suspend_below_min_bitrate:
             stream.allocated_bitrate = min(stream.min_bitrate, bitrate)
             stream.allocated_bitrate = stream.min_bitrate
         bitrate -= stream.allocated_bitrate

One of the problems with this functionality is detecting when this feature is activated to change the UI or notify the receiver that the video has been suspended.  The only solution at this point is using getStats to monitor the encoded video bytes but some kind of callback/notification is under consideration [4]

In case you have the same question I had, the video recovers automatically when the network conditions improves again.   You can see a graph with the whole suspension + reactivation I generated by degrading artificially my network conditions to force a bandwidth estimation < 40kbps.



  1. thanks Gustavo!

    this article reminded me about the one I'm linking below, where @fippo described how to restrict the bandwidth usage and an open issue in Chrome for removing the limit:

    1. Controlling Bandwidth Usage In Webrtc (And How Googsuspendbelowminbitrate Works) >>>>> Download Now

      >>>>> Download Full

      Controlling Bandwidth Usage In Webrtc (And How Googsuspendbelowminbitrate Works) >>>>> Download LINK

      >>>>> Download Now

      Controlling Bandwidth Usage In Webrtc (And How Googsuspendbelowminbitrate Works) >>>>> Download Full

      >>>>> Download LINK n3

  2. Today's colleges and universities are changing with the times. Programs change as do the ways that students are taught. However there is one growing program on almost every public college campus that administrators are not proud to point out to distinguished visitors -- developmental education.

  3. x-google-min-bitrate and googSuspendBelowMinBitrate not working for me. Video never get suspended, when by speed goes below specified Bitrate. Is it still working for you?

  4. Thanks for sharing,
    now, i know how to use it...


  5. Terribly attention-grabbing, sensible job and thanks for sharing such a decent journal. Your article is thus convincing that I ne'er stop myself to mention one thing regarding it. You’re doing a good job. Keep it up

  6. Thanks for sharing this informations.
    data science course in coimbatore

    data science training in coimbatore

    android training institutes in coimbatore

    ios training in coimbatore

    aws training in coimbatore

    amazon web services training in coimbatore

    big data training in coimbatore

  7. This comment has been removed by the author.

  8. Allowing poor performers to hang out too long simply reinforces poor performance. If no accountability is in place, then why should the poor sales performer step up and make an effort? Empty promises and hollow threats from the sales manager don't mean a thing. Salesforce training in Chennai

  9. Check out the maths quiz questions with answers to become effective and increase your level. They provide the best and effective questionnaires to develop yourself.

  10. Don’t follow your role model. Be the Role model person for others. But it's so simple by getting Hadoop training in Chennai. Because it is an assurance course to bounce back from a double salary. For joining call 7502633633.

  11. Everyone knows that office cleaning is a necessary evil, right? We all know that it's a chore that we all dread but at the same time we know that it needs to be done. And, unfortunately, that's especially true for offices that are in need of a bit of a facelift. office cleaning company austin


Post a Comment

Popular posts from this blog

Bandwidth Estimation in WebRTC (and the new Sender Side BWE)

Improving Real Time Communications with Machine Learning