setBandwidth()

setBandwidth({ kbs, trackConstraints })

IMPORTANT: We try to hide all the complexity of WebRTC so that you can focus on your own application rather than the details of audio and video network streams. The bandwidth management we do under the hood should be "the right thing" for most use cases (based on lots of empirical call data, plus experience working around cross-platform quirks).

If you find it necessary to use setBandwidth(), we'd love to talk to you! Please reach out to us and tell us about your use case and what other advanced functionality you might need, so we can best support applications like yours.

Sets a cap on the upstream camera video bandwidth used for WebRTC peer connections, and allows you to modify the constraints of the camera video track.

ParameterTypeDescription
kbsNumber, 'NO_CAP'A soft cap on the upstream video bandwidth used for the camera in kilobits. In small calls (peer-to-peer (P2P) mode), this is a target bitrate for the camera stream sent to each peer. In larger calls, this is a cap on the overall upstream bandwidth used for all simulcast connections. NO_CAP can be used to unset a previous cap applied. Note that the kbs cap does not take into account audio or screenshare bandwidth. We don't currently support customizing audio or screenshare bandwidth settings.
trackConstraintsFunctionA MediaTrackConstraints dictionary that will be applied to the local video track, if possible. It is safest to use standard video resolutions as these are best supported by all browsers and generally have the best encoding performance: 1280x720, 640x480, 640x360, 320x240, 320x180. Very small images can also work well, too: 64x64 and 32x32.

If kbs is not provided (i.e. setBandwidth() is called with only trackConstraints), the bandwidth cap is unaffected. In P2P mode, if the bandwidth has not been explicitly set, Daily defaults to setting the maxBitrate per peer to 980kbs split across the number of connections. E.g. In a 3 person call, maxBitrate would be 490kbs. In SFU mode, if the bandwidth has not been explicitly set, the current encoding settings will be unaffected and the maxSpatialLayer is set to however many layers are currently defined in the encoding settings.

Here's an example of using setBandwidth() to transmit 64x64 images at a frame-rate of 3 images per second, with a target video bandwidth cap of 20kbs per second.

Now works in both peer-to-peer and sfu mode, and no longer triggers a renegotiation. So you can call setBandwidth() without running the risk of renegotiation conflicts, and you can call it with only kbs or only trackConstraints. In peer-to-peer mode the kbs argument is a bitrate target for each peer connection. In sfu mode, we send as many simulcast layers as we can within the kbs cap, starting with the lowest layer. So, normally the kbs cap should be the sum of the bandwidths of the layers to be sent.