Multicamera Livestream Signal Flow: A Worked Example

The whole system in one look

Every multicamera stream, church service, council meeting, corporate town hall, club show, is a variation of the same architecture. Signal converges: many sources into one switcher, one program out of it. Then it diverges: the same program to the recorder, the encoder, and the monitors. Once you see the converge-then-diverge shape, every decision below is just a matter of which stage owns it and what happens when that stage fails.

Stage 1, Acquisition: three cameras, one format

Before a single cable is pulled, decide the system format, resolution and frame rate every device will run, and decide it once, system-wide. Every device that runs something different buys you a conversion, and every conversion is money, latency, and one more thing that can fail. The switcher's native format is usually the deciding vote; the cameras conform to it.

Camera placement drives cable choice, and the enemy is distance. HDMI is a short-run format, beyond a few meters it gets unreliable, so plan extenders or SDI for anything longer and check your cable spec instead of gambling. SDI over coax is the standard answer for long camera runs, which is why broadcast-style cameras and larger switchers speak it natively. The wrong move is assuming a long HDMI run will be fine on site because it worked on the bench.

Stage 2, Switching: program, preview, and the buses you'll want

The switcher is the heart: every source lands on an input, the operator previews the next shot, and one program output carries the show. Count inputs honestly, three cameras never means three inputs. Slides or playback take one, graphics may take another, and you want at least one spare for the guest who arrives with a laptop.

Beyond program/preview, the working feature is the aux bus: an extra output routed independently of program. Auxes feed stage confidence monitors (so the presenter sees the slides, not themselves), lobby displays, or a dedicated recorder feed, without tying up the program path or forcing the stream to watch what the lobby watches.

Stage 3, Audio: the path everyone forgets

Video gets the diagram; audio gets an afterthought, and audio is what viewers actually leave over. The path: microphones and playback land on an audio console; the console builds a dedicated stream mix; and that mix is embedded into the program video signal, at the switcher's audio input or via an embedder. From that point on, "program" means picture and sound traveling together, so everything downstream (record, stream) gets both automatically.

Two concepts carry this stage. First, the stream mix is its own mix: the room PA balance is wrong for headphones and phone speakers, so send the stream a dedicated bus, not a split of the house feed. Second, lip-sync: video processing takes time, so audio tends to arrive early, and the fix is delaying audio to match video at the point where they merge. Set it during rehearsal with a clap on camera; verify it on the stream return, not just in the room.

Stage 4, Record: why the record is not the stream

Record and stream feel like the same act, the program, captured. Separate them anyway. The stream is compressed hard so it survives the trip to the platform; the recorder captures from the same program output at much higher quality. If the master of your event is whatever the platform saved, your master is a heavily compressed copy of a copy.

• Program record, the switched show, from its own program output, on a dedicated recorder.
• ISO records, individual camera recordings, when budget allows, for re-cuts and disaster recovery.
• Failure isolation, the recorder doesn't know the internet exists. Platform outage, encoder crash, ISP failure: the record keeps rolling. That independence is the entire point of the stage.

Stage 5, Encode and stream: one box, one job

The encoder turns program into the compressed stream and pushes it to the platform's ingest. Give the job to a dedicated device, a hardware encoder or a machine that does nothing else. The moment the switching computer is also the encoding computer, one overloaded CPU takes out both jobs at once; that is the single point of failure that ends streams.

Internet, honestly: the primary connection is wired, not the venue Wi-Fi, and tested at the actual ops position before show day. Common practice for anything that matters is a backup path on different infrastructure, typically bonded cellular, so the building's ISP isn't a single point of failure either. Most platforms offer primary and backup ingest entry points; use both when your encoder supports it, and plan bandwidth with comfortable headroom above your stream bitrate, check your platform's published recommendations for your resolution rather than guessing.

Stage 6, Monitoring: watch what the viewer sees

The operator watches a multiviewer, all cameras, preview, and program on one display. Necessary, not sufficient: the multiviewer shows what you're sending, not what viewers are receiving. The stream can be down for ten minutes while program looks perfect on the desk.

So the last device in the system is a stream-return confidence monitor: a separate device playing the actual public stream, with audio spot-checked on headphones. A phone or tablet on cellular is ideal because it also takes the venue network out of the loop. It runs behind by the platform latency; that's fine, its job is one binary answer: are we live, with sound. And give camera operators comms. A camera you can't talk to is scenery.

The full path at a glance

The whole system, stage by stage, and the failure each stage's design is there to contain.

Common mistakes

Every one of these is cheap to fix in preproduction and miserable to fix live:

• No stream-return monitor. The desk looks perfect while the stream is down; the first alert is a text from someone's relative. A phone on cellular playing the public stream fixes it.
• Audio reaches the stream but not the record, or the reverse. Embed the mix into program before it splits to recorder and encoder, and both get it. Patch either one from a different point and you get a silent master or a silent stream.
• The encoder shares a computer with the switcher. One busy CPU, two dead jobs. Dedicate the encode.
• No comms to camera operators. Without talkback you're streaming whatever the operators guess you want. Even a cheap two-wire beats hand signals.
• Format decided per device instead of system-wide. Every mismatch becomes a converter, and converters multiply until one of them is the thing that fails.

Build yours port-to-port

This article gives you the architecture. A buildable system needs every connection drawn to the actual port, which input each camera lands on, where the audio embeds, which output feeds the recorder. That's the method in how to create an AV signal-flow diagram, and once the drawing is port-to-port, the cable schedule falls out of it as a report instead of a retyping job.

Exactly this class of system is what the WireFlow sample show documents, a complete production with signal flow, gear list, cables, and tech pack, open to explore without an account. Then work the preproduction checklist before show week, and the stream becomes the boring part of your day. That's the goal.

Frequently asked questions

Can I build a 3-camera livestream with HDMI only?

For a small room, often yes, HDMI cameras into an HDMI switcher is a legitimate budget architecture. But HDMI is a short-run format: keep runs to a few meters, and for anything longer plan extenders or move to SDI, checking your cable spec rather than assuming. Distance, not camera count, is what pushes systems to SDI.

Do I need a hardware switcher, or is software switching OK?

The architecture is identical either way, inputs, program/preview, aux feeds, one program out. Software switching trades cost for concentration of risk: the same computer becomes capture, switcher, graphics, and sometimes encoder. If you go software, the discipline that matters most is moving the encode onto its own device.

Why is my livestream audio out of sync?

Video takes longer to process than audio, so audio typically arrives early. The fix is delaying audio to match video at the point where they merge, set it in rehearsal with an on-camera clap, then verify on the actual stream return. If sync is right in the room but wrong online, the offset was introduced after your monitoring point.

Do I still need to record locally if the platform saves the stream?

Treat the platform copy as a bonus, not the master. It's compressed for transport, and it dies with the connection, the minutes you most need to recover are exactly the minutes it will be missing. A local program record from the switcher's output survives internet failures and gives you a higher-quality master.

How much internet bandwidth does a livestream need?

Enough for your encoder's stream bitrate with comfortable headroom, crews commonly want at least double, on a wired connection tested at the ops position. The bitrate itself depends on resolution, frame rate, and platform, so check your platform's published recommendations instead of a rule of thumb, and put the backup path on different infrastructure.

See a full show documented in WireFlow

A complete conference production, signal flow, LED wall, rack, gear list, and tech pack, open to explore without an account.

Explore the sample project · Start your own free