Protect the primary programme before distribution.
Distribution architecture
Simulcast with visible failure boundaries
Send one live programme to several destinations while tracking credentials, bitrate contracts, retries and alarms for every output job.
Fan out after a stable ingest when the venue should not maintain every platform session.
Decision map workflow boundary
Each destination gets its own contract and visible runtime state.
A healthy input does not prove every output.
egress budgetoutput isolationrate limitsdestination proof
In broadcast streaming, simulcast is one live programme sent to several destinations at once. A production feed might go to two social platforms and a private partner endpoint, with a separate delivery job for each. In WebRTC, the term usually means something else: one sender produces multiple RTP encodings so a receiver or SFU can choose the right layer.
One word, two video meanings
| Meaning | What is sent | Why teams use it |
|---|---|---|
| Broadcast simulcast | One programme to several platforms or endpoints | Reach separate audiences and partners at the same time |
| WebRTC simulcast | Several encodings of one source, often at different resolutions or bitrates | Let an SFU or receiver select an appropriate layer |
This guide is about broadcast simulcast. The W3C WebRTC specification describes the narrower browser meaning, including multiple encodings configured through sender parameters. Treat them as different workloads: four destination connections are not the same as three WebRTC encoding layers.
Choose where the fan-out happens
| Decision | Encoder-side fan-out | Server-side fan-out |
|---|---|---|
| Source upload | One outbound media stream per destination | One upstream programme to the fan-out service |
| Production machine | Maintains every destination connection while producing the show | Maintains the contribution connection; the server maintains destinations |
| Destination changes | Made on the encoder that is live on air | Made in separate downstream jobs |
| Useful fit | A small destination set, proven upload headroom, and simple event operations | Several destinations, constrained venue upload, or a need to operate outputs away from the production encoder |
| Shared risks | Source machine, local network, encoder configuration | Source feed, fan-out node, shared automation and node capacity |
Neither design is inherently more reliable. Server-side fan-out keeps repeated destination traffic off the venue connection and lets operators control downstream jobs separately. Even then, every output still relies on the source and the fan-out service. For two destinations, encoder-side fan-out can be a sensible choice when measurements show enough headroom on the production machine and uplink.
Design the simulcast as separate contracts
“Send everywhere” is not an operational plan. Before rehearsal, create one record for each destination. Take the current ingest requirements from the platform's official documentation instead of assuming that a generic social-platform preset will work for the account or event.
| Contract field | What to record | Acceptance evidence |
|---|---|---|
| Account and event | Platform account, scheduled event or channel, operator and timezone | The output lands in the intended event, not merely in a valid account |
| Secret | Storage location, person allowed to rotate it, expiry or rotation time | A test connection succeeds without exposing the secret in a ticket or screenshot |
| Ingest route | Protocol, hostname or region, TLS requirement and backup route if provided | The platform reports the expected ingest endpoint |
| Media | Video/audio codec, resolution, frame rate, bitrate ceiling, GOP or keyframe cadence, audio layout | The platform dashboard and public player show the intended programme |
| Control | Start/stop order, alarm route and who may disable one output | The operator can stop and restart this destination alone |
| Viewer proof | Signed-out playback URL, geography or account restriction, expected audio and captions | A clean viewer session starts and remains stable |
Capacity planning for a simulcast
Keep venue upload and fan-out egress as two separate numbers. For encoder-side fan-out, a useful first media-only estimate is source bitrate × number of destinations. With server-side fan-out, the venue sends roughly one source bitrate, while the fan-out point sends the sum of all destination output bitrates. In either design, allow for audio, protocol overhead, retries, probes and operating headroom.
For example, copying one 6 Mbit/s programme to four destinations produces about 24 Mbit/s of media egress at the fan-out point. It is not a 6 Mbit/s end-to-end job, and the estimate is deliberately not a promise of node capacity. If two destinations need different resolutions or GOP structures, budget their decode/encode work and output bitrates separately. Remuxing compatible media puts a very different load on the CPU/GPU than transcoding it.
Measure the real programme during motion and other difficult scenes, then rehearse with the maximum destination set. The streaming bandwidth calculator helps with transfer scenarios, while the bitrate guide offers media-level starting points.
What Callaba can do in this workflow
Callaba Restreams can take one reviewed input and use it for multiple destination jobs. The Restreams API workflow shows how to create one job per destination, start each job and check each output with getStat. Depending on its configuration, a job can remux compatible media or transcode, resize, adjust audio and add overlays. Transcoding requires materially more compute than remuxing.
Runtime status tells you that a Callaba process is active and media is moving. It cannot tell you whether the platform attached the stream to the right scheduled event or whether a signed-out viewer can watch it. For every destination, keep the platform dashboard and a final playback check as acceptance evidence. The Callaba Multi-streaming product page covers the operator workflow.
Run the rehearsal in the failure order
- Start the source. At the configured input, confirm the programme identity, picture, audio, timestamps and measured bitrate.
- Start one private or low-risk destination. Check the job state, the platform ingest dashboard and the signed-out viewer path.
- Add the other destinations one by one. Keep the job ID, start time, measured output bitrate and viewer result for each.
- Stop or invalidate one output. Make sure the source and the other destinations continue, and record any shared effect instead of assuming isolation.
- Restore that output alone. Record the action, the time to stable ingest and the time to public playback.
- Stop the source. Observe the failure state of every output, then restore the source and verify each destination separately.
This order helps separate a source failure from a destination failure or a node-capacity problem. If every output starts at once, the first incident is much harder to localize.
Use the failure scope to choose the first action
| Observed scope | Check first | Avoid |
|---|---|---|
| Every destination fails together | Source input, fan-out process, node health and shared automation | Rotating every platform secret at once |
| One destination rejects ingest | That job's secret, event binding, ingest route and media contract | Restarting the source or healthy jobs |
| Platform says live; viewer fails | Public playback, account state, geography, moderation and player errors | Treating a connected publishing socket as audience proof |
| Quality degrades as outputs are added | Actual egress, CPU/GPU, input stability and per-output transcode load | Raising every output bitrate during the event |
If every destination freezes at the same instant, start with the programme input and fan-out service. If one output fails, leave the healthy sessions running while you inspect that platform's credentials, ingest region, format contract and status page. When dashboards are green but viewers still report a failure, open the public playback routes from a clean network and check account restrictions, geo policy and player state.
Keep destination status, platform health evidence and final playback checks in the event record. “Four sockets connected” is not operational success. Success means that the platform accepted all four destination contracts independently and the intended viewer route was verified for each one.
When not to simulcast
Do not add a destination unless the team can legally distribute to it, moderate it, observe it and support it. If a partner needs a different programme, clean feed, language mix, graphics policy or contractual handoff, treat that as a separate output rather than simulcast. Adding more platforms will not solve a contribution problem either: when the source is unstable, every destination receives the same instability.
Simulcast FAQ
Is simulcasting the same as multistreaming?
In live broadcasting, both terms often describe the same one-input-to-many-destinations job. Product names vary, so check whether the service copies compatible media, transcodes destination-specific outputs or does both.
Does simulcasting require multiple encoders?
No. A single production encoder can send the programme to a server-side fan-out layer. You need separate encodes only when destinations have incompatible media contracts or require genuinely different programmes.
Can one failed platform stop the others?
Independent output jobs reduce coupling, but you still need to test the behavior. A shared source, node, credential process or automation bug can affect several destinations at once.
Is WebRTC simulcast the same thing?
No. WebRTC simulcast usually refers to multiple RTP encodings of one source so a receiver or SFU can choose a layer. Broadcast simulcasting refers to simultaneous delivery to multiple destinations.