Live Broadcast Workflow: Ingest, Recover, Route and Record
More live video workflow notes and product updates.
A live broadcast is an operating system for a moment that cannot be replayed for the crew. Cameras and encoders create the program, contribution links move it, operators watch its health, recovery paths protect it, and delivery turns it into something viewers can open. The useful question is not only “Are we live?” but “Which part of the path is healthy, who owns it, and what happens next if it fails?”
Quick answer
Build the broadcast as one observable path: primary and alternate SRT PULL routes into Callaba; browser Multiview and transport telemetry for operators; configured route cycling after a disconnect; routing, recording and restreaming from the recovered program; and browser playback for the audience. Rehearse the exact reconnect or preferred-route procedure the team will use on air.
- Route
- Record
- Restream
- HLS
A live broadcast is several connected systems
“Live streaming” often describes the act of sending video to viewers. “Live broadcast” adds the production and operational discipline around that stream: named sources, monitored contribution, a program decision, recovery, recording, and a clear destination. The same underlying protocols can support both, but the failure cost and operator responsibilities are different.
Capture and encode
The camera, switcher or software mixer creates video and audio. Resolution, frame rate, codec, bitrate and keyframes must match the next system.
Move the program
SRT is useful for resilient transport over variable networks; RTMP remains common for platform-style ingest. Caller and Listener roles describe connection setup, not who produces the pictures.
See and recover
Operators need picture, audio and transport state in the same operating context, plus an alternate path that is already configured.
Route and record
The accepted source can feed recording, restreaming, Multiview and other production destinations without rebuilding the encoder output for every task.
Reach the viewer
Browser playback commonly uses segmented delivery such as HLS. Its latency and adaptation behavior are different from the contribution protocol upstream.
Own the decision
An alert is only useful if someone knows whether to wait, reduce bitrate, switch source, restart a route or protect the recording.
Build the operational path in Callaba
Create and name the SRT routes
Prepare a preferred SRT PULL upstream and at least one alternate route. Use names that identify the venue, encoder and role rather than generic labels such as “stream 1.” RTMP can still serve other contribution or delivery boundaries, but this failover path is built from SRT PULL routes.
Prove the primary feed in Multiview
Confirm the actual picture and audio in the browser, then inspect bitrate and connection health. Include RTT, packet loss and retransmissions in the SRT preflight check.
Prepare recovery before adding destinations
Configure the upstream route order and observe how Callaba cycles through the prepared routes after a disconnect or failed reconnect. If the operator changes the preferred route, save the configuration and use the controlled stop/start procedure required by the route rather than assuming an instant switch.
Add recording with an explicit lifecycle
Choose continuous or segmented recording, storage and retention. Verify a short completed file with audio before assuming a red recording indicator protects the event.
Route the recovered source
Send the controlled program toward the required SRT, RTMP, browser playback, NDI or downstream production destinations. Add outputs one at a time and preserve the working contribution baseline.
Open the audience path as a viewer
Test the real player or destination outside the operator account. Contribution can be healthy while packaging, access or playback is broken.
Monitor signals that lead to a specific action
A wall of green indicators is not an operating plan. Select a small set of signals and define what the crew does when each one changes. Put the live pictures next to the transport data so technical health never replaces visual confirmation.
Picture and audio
Black frames, frozen motion, silence, clipping and lip-sync problems may exist even when the transport session remains connected.
Incoming bitrate
A sustained drop can reveal an encoder or uplink problem. Compare the received graph with the configured source rate and the program's real motion.
SRT network health
RTT, packet loss and retransmission behavior show how hard the transport is working. A burst longer than the latency buffer can become a visible artifact.
Session continuity
Connection time and resets distinguish one short network event from a repeated reconnect cycle that deserves intervention.
Recording state
Confirm that the correct source is being written and that finished segments can be opened. Recording health is not implied by preview health.
Viewer proof
Open the final player or platform preview. The viewer experience includes packaging, CDN behavior and access controls downstream from ingest.
Failover is a route design, not just a second cable
Callaba recovery starts with multiple prepared SRT PULL upstreams. When the active route disconnects and cannot reconnect, the configured route logic can continue through the available alternatives. Operators can also choose a different preferred route, but that configuration change should follow the controlled save and restart procedure shown in the product rather than being treated as a frame-accurate vision-mixer cut.
Both recovery paths need the same preparation: an alternate source that can connect, compatible audio and video, a destination path that follows the route output, and a drill that proves what viewers and recordings receive during reconnection.
Use Multiview to identify the active pictures and route health during the drill. Interrupt the preferred upstream, observe the reconnect and route-cycling sequence, verify the alternate reaches every output, then restore the primary and follow the configured operational procedure for returning to it.
Keep the event runbook short enough to use
After the broadcast, keep the same timeline for review. Match every visible or audible incident with Multiview observations, transport data, routing changes and the final recording. That is how the next runbook becomes shorter and more reliable instead of merely longer.
Diagnose an incident by where it appears
No input in Callaba
Check encoder output, Caller/Listener direction, address, UDP or TCP port as appropriate, firewall, Stream ID and credentials before touching delivery.
Preview fails but transport is connected
Inspect codec, container, audio mapping and actual incoming bitrate. A handshake proves connectivity, not a decodable program.
Primary is bad, alternate is clean
Switch according to the runbook, then diagnose the primary without holding the audience on the failing source.
Callaba is healthy, platform is not
Check the outbound route, destination key, accepted profile and platform health. Keep the local recording running if the program must survive a delivery outage.
Viewer buffers while contribution is stable
Investigate packaging, rendition bitrate, CDN and player conditions. Increasing SRT latency upstream will not repair an oversized audience rendition.
Recording misses the switch
Confirm whether the recorder follows the controlled program or a fixed input. The intended source relationship must be part of the design, not inferred during the incident.
Live broadcast questions
Do I need SRT for every live broadcast?
No. SRT is useful for contribution over imperfect networks and exposes recovery-oriented transport behavior. RTMP may be the required handoff for a platform, and other protocols can fit local production. Choose each protocol for its boundary.
Should the encoder be SRT Caller or Listener?
A field encoder commonly acts as Caller toward a public Callaba Listener because the venue initiates the connection. SRT decouples connection mode from media direction, so verify the network topology instead of assuming the source must always call.
Is Multiview only a preview screen?
No. In this workflow it is the operator surface for seeing program sources and checking live state before viewers notice a problem. It complements transport statistics rather than replacing them.
Can the broadcast become VOD after the event?
Yes. Verify the completed recording, manage it in File Manager, then publish it through a VOD player or grouped page with the appropriate access rule.
Technical references
See the live path before you build the event
Open the Callaba Multiview demo to see the operator surface for live sources and route state. Then build the preferred input, alternate route, recording and outputs as one rehearsed path in cloud or self-hosted Callaba.
