Backup Stream on DCAST: What Happens When Your Encoder Drops

Every live producer has a story about the moment the stream died: the laptop that decided to update, the venue Wi-Fi that collapsed when the audience arrived, the encoder that overheated in the sun. When you sell tickets to that event, the story also has a refund chapter.

DCAST lets you send a second, backup feed to the same stream. If the primary feed stops, your viewers keep watching the backup — in the same player, on the same link — and the stream returns to the primary once it is stable again. This article explains how it works, what viewers see, and how to set up a backup that actually protects you.

The idea in one paragraph

You run two independent sources for one event — two encoders, or two computers, ideally on two different internet connections. Both send the same show to DCAST. One goes to the stream's normal (primary) address, the other to its Backup URL, using the same stream key. DCAST watches the primary feed. While it is healthy, viewers get the primary. When it stops delivering video, DCAST switches the program to the backup. When the primary comes back and stays healthy, DCAST switches back.

Where to find the Backup URL

Open your stream's settings and look at the Connection tab. Next to the primary server address you will see a second row, Backup URL. On the PRO and VIP plans, every RTMP stream has a Backup URL. On other plans the row is visible, copying it tells you which plan includes it, and the backup address does not accept a feed.

Nothing to switch on: the backup is used when a feed actually arrives on the backup address. If you only send the primary, your stream works exactly as it always did.

The backup uses the same stream key as the primary. You do not manage a second key or a second stream — you configure your second encoder with the Backup URL and the key you already have.

What viewers see during a switch

Viewers do not reload anything. The watch page, the embedded player on your website, the chat and the viewer count stay where they are; only the source behind them changes.

Two honest details:

• The switch is not invisible. At the moment of switching, viewers see a hitch of a fraction of a second while DCAST takes the other feed. The sound is faded out and in at the join so it does not click, but two encoders never produce exactly the same picture and sound at the same instant. What matters is that the stream continues instead of ending.
• If both feeds are lost, the player shows black with silence and keeps waiting, rather than ending the broadcast. As soon as either feed returns, the picture comes back.

Connect the backup before you press Start

Start both encoders before you press Start in DCAST. When the backup is already connected at Start, the broadcast begins on the protected path, and a later failure costs your viewers only the fraction-of-a-second hitch of the switch.

A backup that connects while you are already live still works, but DCAST has to move the running broadcast onto the protected path first. Viewers see one brief hitch at that moment; after it, the backup works as usual.

Why the switch keeps your picture quality

DCAST does not decode and re-encode your picture to switch between feeds. It cuts from one feed to the other on a keyframe — the point where a video stream can be started cleanly. That keeps the switch cheap and keeps your picture exactly as your encoder produced it.

It also gives you one practical rule: set a keyframe interval of 2 seconds on both encoders. A long keyframe interval means the switch has to wait longer for a clean cut.

How to build a backup that actually protects you

A backup protects you only from the failures it does not share with the primary. Before the event, go through this list:

The most common mistake is two encoders on the same laptop and the same Wi-Fi. That protects you from one software crash, and from nothing else.

Make both feeds as similar as you can: the same resolution, frame rate, audio sample rate and keyframe interval. Your viewers will notice the switch less.

What a backup does not replace

Your own recording. Always record the program locally on at least one of your encoders. It is your master copy, independent of any network or platform, and the best source for an edited replay.

A rehearsal. Test the backup before the event: start both feeds, press Start, open the watch page, then stop the primary and watch the stream continue. Start the primary again and watch it return. Five minutes of rehearsal is what turns a backup from a hope into a plan.

Which streams can use a backup

The backup works for streams you send from an encoder over RTMP. Streams sent from the browser camera, pulled from an HTTP source, or played from a file do not use a backup address — the first has no second encoder by design, and the other two are not live encoder feeds.

Who this is for

• Creators who sell access — paid events, courses, subscriptions — where an outage means refunds and lost trust.
• Conferences and churches streaming from venues whose internet is out of their control.
• Sports and outdoor productions where a cellular backup line is the realistic way to protect the show.
• Anyone who has ever had to post "sorry, we lost the stream".