One ingest, independently operated outputs
Send one live feed to several destinations without making the encoder carry every upload
Multistreaming takes one verified source and publishes it to several platforms or private endpoints at the same time. With Callaba, the encoder sends one upstream feed to an SRT or RTMP Server. Operators see that source, then create a separate Restream job for each destination. A failed stream key or platform outage can be repaired without rebuilding the source or stopping every other output.
The Callaba product model
Receive the program once, inspect it in the browser, optionally record it, and fan it out through independently configured Restream jobs. Keep pass-through when the incoming codecs and format already satisfy a destination. Enable transcoding only for an output that needs a different codec, resolution, frame rate, bitrate, audio layout, or overlay. The operator experience comes first; the Restream API is available after the manual workflow is known to work.
The moving window recalls an operator watching the source bitrate while packets branch toward destinations. It demonstrates workflow logic, not measured telemetry; reduced-motion settings stop all movement.
Choose where the fan-out should happen
Sending several outputs directly from OBS or another production computer can be acceptable for a small, low-risk stream. It also multiplies local upload traffic and ties every destination to one workstation. A cloud or self-hosted relay changes that boundary: the venue publishes once, while the Callaba host carries the outbound connections. That can simplify the local link and make destination recovery more deliberate, but it does not remove the need to size the relay, monitor the source, and respect every platform’s requirements.
Fan out at the encoder
Useful for a fast experiment with few outputs and abundant upload capacity. The production machine, plugins, and local network become a shared failure domain.
Fan out in Callaba Cloud
Useful when venues should send once and the output layer should run near scalable cloud connectivity. The team still owns platform credentials and event monitoring.
Fan out self-hosted
Useful when network placement, private endpoints, data policy, or predictable infrastructure ownership matters. Capacity, updates, security, and recovery remain your responsibility.
Build the first two-destination workflow
Prepare each destination independently
Create or schedule the live event at each platform. Copy the current ingest URL and stream key through an approved secret-handling process. Record required codecs, resolution, frame rate, keyframe interval, audio format, and the time at which the destination will accept a feed. A stream key is effectively a publishing credential; never place it in article screenshots, source control, or a shared runbook.
Create one Callaba ingest
Choose an SRT Server when remote contribution needs the SRT transport model, or an RTMP Server when the source publishes RTMP/RTMPS. Create, start, and permit the required port. Copy the correct Publisher URL into the encoder and send a representative program. Confirm sustained bitrate, picture, audio, and reconnect behavior before any public output is added.
Observe and optionally record the source
Place the input in Multiview so an operator can verify actual media rather than trust a connection badge. If an archive is required, start the recording workflow and inspect the first file. This clean source boundary becomes the comparison point when one downstream platform reports a problem.
Create the first Restream job
Select the verified ingest as the input and the first platform or endpoint as the destination. Enter its exact credentials. Begin with pass-through when source and destination requirements match; otherwise apply one measured output profile. Start the job and confirm both Callaba statistics and playback at the destination.
Add the second destination as another job
Do not put several destinations into an ambiguous shared object. Create a second Restream job, use its own URL/key and output profile, then test it without changing the working first job. Give jobs names that make incidents obvious, such as “Program → YouTube” and “Program → Partner RTMP.”
Rehearse an isolated failure
Stop or invalidate only the second destination. Confirm the source, recording, and first platform continue. Restore the affected key or job and measure recovery. If every output stops, the architecture still contains a shared failure you have not isolated.
Pass through by default; transcode for a named reason
Transcoding is valuable when a destination cannot accept the incoming media or needs a deliberate alternate rendition. It also consumes CPU or accelerator capacity, adds latency, and creates another place for video or audio to be changed. For several platforms that accept the same program profile, one compatible source plus pass-through outputs is the simpler baseline.
| Decision | Pass-through case | Processing case | Acceptance evidence |
|---|---|---|---|
| Codec and raster | Source already matches the receiver’s current specification. | Destination requires another codec, resolution, scan format, or frame rate. | The platform reports a healthy ingest and the public player shows expected motion/detail. |
| Bitrate | Source rate stays inside the destination’s allowed range with network headroom. | A separately controlled output rate is required for compatibility or capacity. | Callaba output and destination health remain stable through representative motion. |
| Audio | Existing codec, sample rate, channels, and track match the receiving contract. | A platform needs another channel selection, layout, or audio encode. | Every published player has the correct language, channels, and sync. |
| Graphics | The source program already carries the correct clean or branded image. | A destination-specific image overlay is required and rights are approved. | Safe areas and legibility pass on desktop, mobile, and platform preview. |
For YouTube specifically, use its current live encoder settings rather than a copied profile from an old article. Other services publish their own requirements and may change endpoints, keys, eligibility, or supported formats.
Operate destinations as separate services
Source healthy, one platform offline
Leave the encoder and other outputs untouched. Inspect the affected Restream job, its destination event state, credentials, output bitrate, and codec requirements.
All outputs degrade together
Return to the shared boundaries: source encoder, contribution network, Callaba ingest, host resources, and common network egress. Compare the incident clock with source bitrate.
Platform preview works, audience playback does not
Check the platform’s event visibility, publication state, rights controls, regional policy, and viewer page. An accepted ingest does not guarantee that the event is public.
Size the shared boundaries
The venue upload carries the single contribution feed plus operational overhead. The Callaba host or cloud environment carries every outgoing stream and any transcoding load. Estimate outbound bandwidth from the sum of destination bitrates, then add capacity for recording, previews, protocol overhead, monitoring, and peaks. CPU or accelerator planning must reflect the number and complexity of processed outputs, not merely the number of Restream jobs.
Run the full destination set for long enough to see stable-state thermals, bitrate, memory, and reconnect behavior. A five-minute idle scene rarely reveals the capacity used by a fast-moving program with graphics and several transcodes.
Keep product operation and automation connected
The Callaba Multistreaming product page explains cloud and self-hosted options. Use the Re-streaming and transcoding guide to configure source, destination, pass-through, processing, audio, and overlays. Use SRT Servers or RTMP Servers for the ingest boundary. After two outputs pass the failure rehearsal, the Restreams API can create, inspect, start, stop, or update repeatable jobs. Preserve the destination-per-job model in automation so one credential change remains isolated.
Preflight card for the operator
- The source is visible with correct picture and every required audio channel.
- Each destination event exists, accepts input, and has an owner with permission to rotate its key.
- Every Restream job names one source and one destination unambiguously.
- Pass-through or processing has a documented reason per output.
- Host resources and outbound network were measured with the complete set running.
- At least one platform failure was restored without interrupting the others.
- The team watches real audience playback, not only ingest dashboards.
Start with one ingest and two outputs you can break independently
That compact rehearsal proves the architecture. When both destinations recover without forcing a new source connection, adding the next platform becomes a controlled operation rather than another load on the production encoder.
