Redundant Ingest

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

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 feeds, which will be automatically delivered to viewers in the case of a problem with the original feed. 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 feed that uses a different encoder.

When publishing multiple backup feeds, you can establish an order in which the feeds should be selected. The Dolby.io Streaming platform provides the priority parameter that lets you set the priority of each feed. In the case of any problem with the primary feed, viewers receive the available feed that has the highest priority. Not setting any priorities or setting the same priorities results in receiving the most recently published feed.

The following instructions explain how to publish redundant feeds using Streaming APIs. 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 feed.

2. Create a publish token

Open the dashboard and click the Create button to create a new token.

3. Choose the preferred cluster regions

Select your token name to open token details and locate the Settings section. Choose the preferred Cluster region from the drop-down list. Selecting a cluster impacts the domain name in the publish path. We recommend choosing two regions in the same geographical area: the closest region to the publisher as the primary region and the farther region as the backup. To use two cluster regions, use two publish paths, one for each region you want to use.

4. Set priorities

Use the priority query parameter to define the order in which your feeds should be selected. To set the parameter, add &priority=X at the end of your publish URL, where X is an integer between -2,147,483,648 and 2,147,483,647 (inclusive). 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&priority=1.

If you use Simulcast with Redundant Ingest, you can assign priorities and sourceId as presented in the following example:

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.

Publishing redundant feeds using the dashboard, Client SDKs, or WHIP

Follow this procedure to broadcast multiple redundant feeds and provide a reliable streaming experience using the dashboard, a Client SDK, or WHIP.

1. Establish your broadcasting plan

Decide how many layers of redundancy you want for a given feed.

2. Create a publish token

Open the dashboard and click the Create button to create a new token. If you want to use two cluster regions, create two tokens.

3. Choose the preferred cluster regions

Select your token name to open token details and locate the Settings section. Choose the preferred Cluster region from the drop-down list. If you want to use two clusters, additionally open the details of the second token and select a different cluster from the list.

4. Set priorities

Use the priority parameter to define the order in which your feeds should be selected. The parameter has to be an integer between -2,147,483,648 and 2,147,483,647 (inclusive).

If you use Simulcast with Redundant Ingest, you can assign priorities and sourceId as presented in the following example:

If you use the dashboard, open the Streaming Dashboard Broadcaster and click the gear icon to open Media Settings. Set the Priority parameter to a preferred value and click Update.

If you use WHIP, set the priority query parameter by adding &priority=X at the end of your publish URL, where X is the preferred priority. 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&priority=1.

If you use a Client SDK, set the optional priority parameter in publisher options, as in the following examples:

millicast::Publisher::Option options;
options.priority = 1;
publisher->connect();
// Wait for the on_connected callback
publisher->publish(options);

Publisher.Option publisherOption = new Publisher.Option();
publisherOption.priority = 1;
publisher.connect();
// Wait for the onConnected callback
publisher.publish(publisherOption);

let publisherOptions = MCClientOptions()
publisherOptions.priority = 1
publisher!.connect()
// Wait for the onConnected callback
publisher!.publish(with: publisherOptions)

const publishOptions = {
  // Other preferred options
  priority: 1,
};

// Start publishing a stream
try {
  await publisher.connect(publishOptions);
} catch (e) {
  console.error('Connection failed, handle error', e);
}

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.

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.