Redundant Ingest

To provide a resilient and reliable streaming experience, the Dolby.io Streaming platform allows broadcasting multiple redundant contribution streams. This solution ensures seamless content delivery to viewers, even in the case of unexpected technical issues.

For more detail on modifying primary and backup streams, see our High Availability Management guide.

Recovery mechanism

To ensure that streamed content will be delivered to viewers, you have to consider the potential problems that may affect broadcasting, such as equipment malfunctions or service interruptions caused by technical glitches or network failures. To avoid such problems during an important event, consider using multiple layers of redundancy including encoders, internet service providers (ISPs), and publishing regions offered by Streaming APIs. Using Dolby.io Streaming, you can publish additional redundant streams, which will be automatically delivered to viewers in the case of a problem with the original stream. For example, in the case of a malfunctioning encoder in the primary broadcast, the platform can seamlessly continue the broadcast as long as there is another live contribution stream that uses a different encoder.

When publishing multiple backup feeds, you can establish an order in which the streams should fail over. The Dolby.io Streaming platform provides the priority parameter that lets you set the priority of each contribution stream. In the case of any problem with the primary stream, viewers receive the available stream that has the highest priority. Not setting any priority is equivalent to assigning the lowest priority to that stream.

The priority value of your stream is set in the Publish Token and affects all streams assigned to that token. Therefore, it is a best practice to use a 1:1 relationship between a publishing token and a stream. If you use a token with multiple stream names or a wildcard token to allow any stream name, a priority change will impact all streams utilizing the token.

Previously priority was set in a Publishing Parameter. For backward compatibility, if both values are set, the priority value from the Publishing Parameters overrides that of the Publish Token. We recommend all customers utilizing High Availability with backup publishing to migrate to using the Publish Token method to set priority.

The following instructions explain how to publish redundant streams using Streaming APIs.

👍

Geo-cascading Settings

Be aware that all publishers that contribute to the same stream must have the same geo-cascading settings.

Publishing redundant feeds using RTMP or SRT

Follow this procedure to broadcast multiple redundant feeds and provide a reliable streaming experience using RTMP or SRT.

1. Establish your broadcasting plan

Decide how many layers of redundancy you want for a given source. Usually, 2 is sufficient for high-value streams.

2. Create a publish token for each layer of redundancy

Open the dashboard and click the Create button to create a new token, or create one via the API. Instead of "auto", choose the closest ingest region to your encoder. Following the example below, set the priority to 100 for your primary. Set a streamName.

Create a second publish token for your backup ingest in the next-closest geographical region. This token must have the same streamName as the primary. Following the example below, set the token priority to 1.

Make sure that geo-cascading is also configured the same across both primary and fallback backup tokens.

3. Publish your streams

If you are using multi-bitrate publishing, you can still utilize multiple quality renditions/layers, the token's priority value will determine their status as primary or backup streams.

For example, if your publish URL is {StreamName}?token={Token}&sourceId=1, after adding the priority parameter with a value of 1 you should have the following string: {StreamName}?token={Token}&sourceId=1.

If you use Multi-bitrate (MBR) contribution where you encode your layers from the studio or video operations center with Redundant Ingest, you need to assign uniquesourceId to each layer, but match each layer's sourceId across your primary and backup token. For a primary and backup ingest as described above, the result would look like this:

Notes

• sourceId needs to be distinct within the MBR group for each layer but match between your primary and your backup
• If using MBR and multi-source contribution, your simulcastIds and sourceIds need to be consistent between primary and backup grouping. More on how to do MBR and Multi-source contribution can be found in our Multi-Source builder guide .

5. Start broadcasting

Start broadcasting the original feed and all backup feeds. In the case the source disconnects, viewers will be automatically switched over to receive the backup feed that has the next highest priority. The switchover duration varies depending on the used broadcast protocol.

Changing priority for a running stream

If you have encoder problems or need to cycle an encoder out for maintenance, you can force the service to change to the backup stream by changing the priority values with the High Availability Maintenance API. See more details in our High Availability Maintenance Guide.

Cost calculation

Pricing is determined based on bandwidth consumption, so each feed is billed independently. For playback, only one feed is distributed, so only data sent to the viewer count as usage, regardless of the number of redundant feeds.

If you have any questions or suggestions, feel free to contact us.