Most contribution designs spend their redundancy budget on the network: a second ISP, a cellular bonding unit, a backup circuit nobody has tested since installation. The encoder in the rack at the venue usually gets one unit, because it is a box that does not fail often. It also happens to be the one component that every path depends on. If it locks up ten minutes before kickoff, the second uplink has nothing to carry.

Contribution is where the single point of failure lives

In contribution, the signal leaves the venue as SDI and becomes IP at an encoder on site. Everything downstream, the distribution chain, the headend, the transcoding, assumes that feed exists. Downstream systems can be built with redundancy in the cloud or in a data center, where adding a second instance is cheap. On site, space, power and crew time are limited, so the encoder tends to be the part nobody doubles.

The design that follows from that is not complicated. Two encoders, one primary and one backup, both fed from the same SDI source and both sent to the same destination. A Premio or a Brutus can fill either role, and nothing says the two have to be the same model. If the venue has several feeds to cover, choosing encoder density decides how many units the pair has to be. What matters is that the backup is already running and already sending, not sitting in a case waiting to be configured after the primary dies.

Warm standby versus cold spare

The difference between those two is the whole design. A cold spare protects you from a dead unit, but only after someone notices, walks to the rack, cables it and loads a configuration. In a live event that is minutes, and minutes are exactly what the contract does not allow. A warm backup is already encoding the same source and already delivering to the destination, so failing over means the receiving side choosing the other feed, with no one touching the venue rack.

That moves the real question from the encoder to the receiver: where does the switch happen, and what decides it? If the answer is “an operator watching a multiviewer,” you have redundancy on paper and a reaction time that depends on who is on shift. Brutus Cloud lists input failover to keep continuity when the source goes down, which makes it a natural landing point when the destination is distributed rather than a headend. If the feeds go to a CDN headend instead, the switching logic belongs there, and it should be specified before the event, not discovered during it.

What goes in front of the receiver

Once two feeds arrive over SRT, the receiving end has work to do before any switching decision is made. Each feed has crossed the public internet on its own, so each has its own packet loss and jitter, and recovery time adds to your end-to-end latency. A Dozer SRT gateway sits at that point as a receiver, recovering lost packets, reordering and absorbing jitter, then handing off clean UDP unicast or multicast to the headend. The feed also stays encrypted in transit, since Dozer supports AES-128 on the SRT link.

Because Dozer works with other vendors’ SRT devices, the same receiver can sit behind encoders that are not DVEO’s, which matters when the venue brings its own.

Path diversity is a separate decision

Two encoders on one uplink protect you from a hardware failure and nothing else. If the venue’s circuit goes down, both feeds go with it. Path diversity is its own layer: two ISPs, or a wired link plus a cellular one, each carrying a feed. SRT fits into designs like that, with multi-path routing and hybrid IP plus 4G/5G failover among the approaches the protocol makes possible.

To be specific about our own gear: our encoders do not do multi-path SRT today. In practice, path diversity with DVEO hardware means two encoders on two separate uplinks, each sending its own SRT stream, with the switching done at the receiver. It is a heavier design than a single multi-path stream, and it is also simple to reason about, since each feed is a complete, independent chain.

Test the failover you drew

The failure that matters most is the one nobody rehearsed. Before an event, pull the primary encoder’s power while the backup is running and watch what the receiver does and how long the output takes to recover. Do the same with the primary’s uplink. If you only test the case you expected, you find the other cases live.

If you are designing a contribution for an upcoming event and want to review the encoder pair, the receiver and where the switch sits, our team is available for a technical conversation. Book a free demo here.