Send one feed to Callaba, then run every destination as a separate output. If YouTube fails, Facebook, Twitch, the recording and the incoming feed keep running.
SRT, RTMP or another supported source
Check the incoming feed, then assign outputs.
Give every destination its own output
“YouTube” is not a complete configuration. A scheduled event can use a different key from tomorrow’s persistent stream. A custom RTMP endpoint may accept a connection but reject the video or audio. Treat each destination as a separate job so one failure stays local.
Build this path in Callaba
Create or select the SRT or RTMP input, open Multi-streaming, and add one output for each platform. Every output keeps its own URL, key, status and retry path.
The same input can also appear in Multiview and Recording. The source connects once; Callaba reuses it inside the workflow instead of asking the encoder to upload a separate copy for every job.
Keep three facts beside every output
Where does it publish?
Save the exact server URL and keep the stream key in the controlled system, not in screenshots or chat.
What will it accept?
Check codec, resolution, frame rate, keyframe interval, bitrate ceiling and audio format.
What counts as live?
Use both the destination dashboard and a viewer-facing check. A connected publisher alone is not proof of moving video.
YouTube’s current encoder guidance ties H.264 ingest rates to resolution and frame rate and asks operators to watch stream health during an event. Twitch provides Inspector for a bandwidth test before viewers become the test. Each output therefore needs its own evidence, even when every job starts with the same feed.
Make one bad endpoint boring
What not to do
One destination disconnects, so the encoder is restarted. Every healthy output drops, the recording gains a gap and the evidence needed to diagnose the original failure disappears.
What should happen
Only the failed output changes state. The incoming feed, recording and other destinations continue while the operator retries or replaces that one job.
Isolation also makes bandwidth easier to reason about. One 8 Mbps contribution plus three server-side outputs is different from three 8 Mbps uploads leaving the venue. The outbound load moves to the Callaba host; any destination that needs transcoding also adds codec work there.
Check the path from source to viewer
| Observation | What it confirms | What remains unknown |
|---|---|---|
| Input bitrate is moving | The contribution reaches Callaba | Whether any destination is publishing |
| Output process is connected | The remote endpoint accepted a session | Whether public playback has current media |
| Destination dashboard is healthy | That platform accepts the current output | Whether other outputs are healthy |
| Viewer playback advances | One real delivery path reaches a browser or app | Whether every region and device works |
Rehearse a partial failure before the event
Run the real source, confirm every destination in its own dashboard and viewer, then stop one output deliberately. The input, recording and remaining outputs should stay healthy. Restart only the failed job and note how long it takes for public playback to move again.
A useful restream test leaves a receipt: one input, independent output states, destination-specific evidence, no collateral restart and a named owner for every credential. The Restreaming user guide shows the operator controls.
Primary references: YouTube Live encoder settings and Twitch Inspector.
