The Dolby.io platform manages network traffic when distributing a stream to provide a stable, highly available end-user experience. For system architectures that make use of complex broadcast equipment on-site, there is potential for disruption if any component from the broadcast workflow were to fail.

To enable resiliency while streaming, we provide backup publishing to configure a redundant parallel ingest source. When content is distributed to the audience, if one of the incoming streams were to fail, the platform detects the scenario and will failover to the backup source.

Backup Publishing Stream

To enable redundant ingest broadcasts, you provide independent parallel sources. The default behavior when publishing a live feed is that any previously published live feed is overwritten so that viewers always watch the most recently published stream. This behavior provides redundancy when streaming content is sent by the CDN.

Depending on the broadcast location, venue, event type, and scope, your circumstances will influence how much redundancy you need in your solution. You may also consider:

• Separate capture cameras or devices
• Separate hardware or software encoders

If the primary broadcast were to have a malfunctioning encoder, as long as the first published live feed was still broadcasting, the platform would seamlessly continue the broadcast. This behavior is available regardless of which broadcast protocol is used (WebRTC, RTMP, SRT, etc.)

You can send identical content or an alternative. Backup publishing can be utilized to distribute content such as content sources indicating:

• The broadcast will begin shortly
• We are experiencing technical difficulties, and the broadcast will resume again shortly

👍

Getting Started

If you haven't already, begin by following the Getting Started tutorial to create a Dolby.io application and start your first broadcast. You will need to have a publishing token.

How-to Enable a Backup Publish Stream

You can enable two or more streams as a backup by publishing with the same token.

1. Configure your Publish Token

You will use the same publish token for all backup streams.

• The cluster region used will be identical for both the main and backup since it will be using the same publish token. This is managed by the platform should an available broadcast region need to failover.

If you are using multisource and multi-view you would use the same sourceId for each corresponding backup source.

2. Sequence the Broadcast Order

The order in which you begin streaming will indicate which is treated as the backup. This may be significant if the backup stream has different content or quality from the primary broadcast.

1. Start broadcasting the backup source. Confirm that all multisource layers and stream audio have started before moving onto the main primary stream.
2. Start broadcasting the main stream.

Viewers will connect to the most recently started stream within the same region, which is why you must start the backup encoder first. In the event that the main encoder goes offline, viewers will automatically be switched over to the backup encoder. The switchover duration will vary depending on the broadcast protocol being used.

How-to Calculate Costs for Backup Publishing

Pricing is determined based on bandwidth consumption, so each ingest source will be billed independently. For playback, only one stream is distributed, so only data sent to the viewer counts as usage in the plan regardless of the number of redundant streams.

Troubleshooting

❗️

Need Help

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