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.
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:
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
You can enable two or more streams as a backup by publishing with the same 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.
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.
- Start broadcasting the backup source. Confirm that all multisource layers and stream audio have started before moving onto the main primary stream.
- 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.
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.
If you have any questions or suggestions, feel free to contact us.
Updated about 1 month ago