Inside a streamed show: how the outgoing feed is built and watched

A streamed event is decided long before the doors open. When we take a booking, the first thing I ask for is a plain list of what will feed the show: how many cameras, which laptops, whether there are remote guests, and where the venue's internet connection actually enters the building. From that list I draw a signal map on paper. Every source gets a line, every line gets a destination, and every destination gets a name that the whole crew will use on the day. This habit looks fussy until the first minute of a rehearsal, when someone says that the second input has gone dark and four people instantly know which cable, which converter and which port they are talking about. Shared names are the cheapest piece of equipment we own, and they cost nothing to carry.

The paper map also tells me what we are missing. A camera with a long cable run needs a different kind of connection from one that sits beside the desk. A presentation laptop may need a converter that nobody has thought about. I would rather find these gaps on a quiet afternoon at the workshop than in a corridor at the venue with the audience arriving.

• Name every source and destination in plain words
• Mark long cable runs and awkward connections
• List what the venue's network can really carry

On the day we arrive early and build in a fixed order. Power first, then the rack, then the monitors, then the signal path from the furthest camera inwards. Each cable is labelled at both ends before it is plugged in, because labelling afterwards never happens. The portable rack holds the switcher, the encoder, the router and a small monitoring wall, and it is wired the same way every time so that any of us can read it at a glance.

We test each source on its own before testing them together. A picture that looks fine on a small preview can still carry the wrong frame rate or a stray audio channel, and these faults are far easier to catch one at a time. Only when every input is clean do we bring the switcher into play and build the layouts the director has asked for.

• Power, rack, monitors, then cameras from the far end
• Label both ends of every cable before connecting
• Test each input alone, then in combination

The encoder is where the show stops being broadcast television and becomes a stream, and it deserves more attention than it usually gets. We choose settings from the connection we can prove, not from the connection we are promised. A speed test in an empty hall says little about the same line when a hundred phones join the network, so we ask the venue about its upload arrangements early and, where the stakes justify it, we plan a second route out. Bitrate is set with headroom, never at the edge of what the line can carry.

A stream that is a little softer but never stalls is a better show than a sharp one that freezes. We also prepare the destination in advance, so that the platform receiving the feed has already seen a short test from us and nobody is entering keys under pressure.

• Choose settings from a tested connection
• Leave headroom on bitrate
• Send a short test to the destination beforehand

Once the show is live, one person on our side watches the outgoing feed rather than the room. This is a separate job from switching, and keeping it separate is deliberate. The vision mixer looks at the sources and the director's cues; the monitor looks at what the audience is actually receiving, including the small delay, the audio level and any sign that the encoder is struggling.

I keep a plain log through the show with a few short lines, noting the time of any dropout, however brief, and what we did about it. It is not paperwork for its own sake. If a problem repeats, the log shows a pattern, and a pattern points to a cause. After the event the log goes to the client with a short summary, so they know what happened without having to ask.

• One person watches the audience's view, not the room
• Check delay, audio level and encoder load
• Keep a short timed log of every dropout

Something small usually does go wrong, and the work is mostly in how quietly it is handled. We talk through the likely failures in the briefing: a lost camera, a laptop that sleeps, a connection that wobbles. Each has a named response and a named person to carry it out, so nobody has to decide anything in the moment except whether to start.

The intercom is the most important tool here, and the rule is short sentences and no raised voices. Say what has happened, say what you are doing, say when it will be done. A calm crew keeps the director calm, and a calm director keeps the picture steady. Viewers rarely notice a fault that was met this way, which is exactly the point of rehearsing for it.

• Agree a response for each likely failure
• Assign one person to carry out each response
• Use short, factual messages on the intercom

When the stream closes we do not pack up at once. We confirm with the client that the recording is complete and playable, check that the platform has finished processing, and only then begin to strike the rack. Cables come out in the reverse order they went in, and each is coiled and returned to its own case.

Back at the workshop the rack is opened again and anything that behaved oddly is looked at while the memory is fresh. A connector that felt loose gets replaced, a setting that needed correcting is written into the template for next time. None of this is visible to the audience, but it is why the next show starts from a better place than the last.