Live production preflight
Five setup mistakes that usually reveal themselves after the stream starts
A live production rarely fails because somebody forgot a fashionable piece of equipment. It fails because the team never agreed on the signal path, tested the real uplink, listened to the program audio, rehearsed recovery, or proved the viewer output. Treat setup as an acceptance test, not a shopping list.
The moving marker represents a rehearsal progressing through the gates. It is illustrative and stops when reduced motion is requested.
1. Planning the show, but not the failure
A rundown explains what should happen. A production plan also names who changes a route, who talks to the venue, where the backup source lives, and what viewers should see while recovery is under way. Without those decisions, several capable people may make conflicting changes during the same incident.
2. Testing internet speed instead of the production uplink
A browser speed test is only a snapshot. The production test must use the intended encoder, bitrate, protocol, venue network and destination for long enough to expose congestion and unstable routing. Leave upload headroom for retransmission, talkback, remote control and other venue traffic.
Watch the signal where it enters production. Callaba can expose live bitrate and SRT round-trip time, while Multiview provides the decoded operator view. A healthy socket is not proof that the picture and audio remain usable.
3. Treating audio as a final polish
An audience will tolerate an imperfect camera angle longer than clipped, missing or unintelligible speech. Check every microphone, embedded channel, remote return and program mix. Listen after the contribution link, not only at the local mixer, because channel mapping and synchronization can change downstream.
4. Adding automation before the manual path is understood
Automation is valuable when it repeats a known-good action. It is dangerous when nobody can explain which source, route or output the action changes. First prove one input, one production path and one destination from the UI. Then automate that exact sequence and keep an operator override.
For recurring events, use the Callaba operator guide to document module ownership, and introduce the Video API only after the product workflow has passed a rehearsal.
5. Testing equipment separately instead of running the show
A camera test does not prove the switcher. A switcher test does not prove contribution. A preview does not prove the recording or audience player. Run the busiest scene, every expected audio source, the live encoder, the backup route, recording and a clean viewer session at the same time.
A compact acceptance checklist
- The signal map names every source, transform and destination.
- Each critical boundary has one operator and one fallback action.
- The full uplink has run with the intended codec and bitrate.
- Program audio was heard after contribution and in the viewer.
- Primary and backup feeds were proved independently.
- Multiview identifies source state before viewers report trouble.
- A real recording was reopened and checked for audio and duration.
- The team knows which changes are frozen before the event.
Build the rehearsal around a visible live path
Start with one real contribution feed, observe it, route it, record it and verify the audience result. Expand only after that chain survives the failure test.
