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.
Most multi-user apps with broadcast consumption need some form of backend that decides what content to show to which users when.
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.
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 in a loop or using webhooks are robust ways to ensure your backend's state covers these situations.
Stream health and uplink speed tests
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 Broadcaster.Observer onStreamHealthUpdate interface method to get regular updates about the stream health while broadcasting.
Uplink speed test API
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 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 method.
Implement the Broadcaster.UplinkSpeedObserver onUplinkTestComplete interface and call the Broadcaster setUplinkSpeedObserver() 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() method.