When you build a solid broadcasting app there are a few behaviors to consider.
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.
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
in a tight loop. The
live=true parameter can be quite handy in this situation.
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:
Put simply, the broadcasting phone can't reliably notify your backend in these scenarios.
Polling the broadcast API in a tight loop using the
live=true parameter is a robust way 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.
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.
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.