⚠️  Sunset Notice: This service will be discontinued as of September 30th, 2023.  Learn more »

Did you come here for Live Video Shopping?

This is documentation for Bambuser Live Streaming SDK.

If you're looking for documentation regarding Live Video Shopping (opens new window) , see these pages (opens new window)

Broadcasting tips

When you build a solid broadcasting app there are a few behaviors to consider.

Screen lock behavior

If you lock the screen during a broadcast, the capture session - and hence the broadcast - ends, in most situations.

This means disabling auto-lock is desired in most broadcasting apps.


The iOS SDK disables auto-lock automatically while broadcasting.


On Android, the recommended way to disable auto-lock while broadcasting is to set FLAG_KEEP_SCREEN_ON (opens new window) in your Activity (opens new window). This approach requires no extra permissions and is used in our example app.

Broadcast starts

Most multi-user apps with broadcast consumption need some form of backend that decides what content to show to which users when.

To detect new broadcasts, your backend can poll the broadcast API (opens new window) in a loop, or you can implement webhooks.

An alternative / complementary workflow: the iOS and Android SDKs provide a callback which fires once the broadcast is fully established, and includes an id which your backend can use to fetch metadata.

Broadcast ends

For apps where a list of live broadcasts are shown to other users, it is often also important to keep track of when a broadcast transitions from being live to being archived.

In the normal case, the user presses a button in your app to end the broadcast, and the broadcasting library provides a callback which you can forward to your backend to pick up the new state quickly.

But there are other ways a broadcast might end:

  • User locks the phone
  • User enters a spot of bad connectivity
  • User runs out of battery
  • ...

Put simply, the broadcasting phone can't reliably notify your backend in these scenarios. Polling the broadcast API (opens new window) in a loop or using webhooks are robust ways to ensure your backend's state covers these situations.

The broadcasting SDKs have built-in mechanisms for coping with varying network conditions. The goal is to provide a high video frame rate and as high video quality as possible at low latency. The SDKs expose APIs for observing the stream health during broadcasting, and determining the available uplink speed before starting a broadcast.

Stream health API

The stream health value is a measure of the current live broadcast frame rate, given as a percentage of the frame rate produced by the device's camera. If the stream health is between 70 and 100, the SDK is sending a high frame rate stream to the servers. If the stream health goes lower, the SDK may adjust the resolution and video bitrate to reach a higher frame rate again.

Short dips in the stream health can occur during normal usage on fluctuating mobile networks, as the SDK can take a moment to adapt.

However, if the stream health stays low for a significant time, it indicates that the network bandwidth is insufficient, the SDK has reached the lowest video quality and resolution is will produce, and the viewing experience will be negatively impacted. It may be useful to show a warning about insufficient bandwidth in the broadcasting app.


Implement the BambuserViewDelegate healthUpdated (opens new window) delegate method to get regular updates about the stream health while broadcasting. Alternatively check the value of the BambuserView health (opens new window) property.


Implement the Broadcaster.Observer onStreamHealthUpdate (opens new window) interface method to get regular updates about the stream health while broadcasting.

The SDK performs automatic uplink speed tests every time a broadcaster instance prepares itself for broadcasting. The speed test results can for example be used to decide whether the end user should be allowed to broadcast or not.


Implement the BambuserViewDelegate uplinkTestComplete (opens new window) delegate method to get the results when an automatic or manual uplink test has been completed.

Extra speed tests can be started manually using the BambuserView startLinktest (opens new window) method.


Implement the Broadcaster.UplinkSpeedObserver onUplinkTestComplete (opens new window) interface and call the Broadcaster setUplinkSpeedObserver() (opens new window) method to get the results when an automatic or manual uplink test has been completed.

Extra speed tests can be started manually using the Broadcaster startUplinkTest() (opens new window) method.