Treating the stream as an afterthought
The most common mistake I meet is planning the room, the cameras and the running order in detail, then leaving the stream until the final week. Someone assumes the venue network will cope or that a laptop with an encoder installed will do. Then the first rehearsal reveals that the upload is shared with the box office, the signal arrives in the wrong format, or nobody knows who owns the streaming account.
A streamed event has two audiences at once: the people in the room and the people watching at home. The second group cannot tap anyone on the shoulder. If the picture freezes, they leave. So the outgoing feed deserves its own owner from the first planning call, with a named person who answers for what viewers actually see.
When we take on live streaming production, we ask about the stream before we ask about lighting. Where will it be published, who holds the logins, how many people are expected to watch, and what happens if the feed drops. Those answers shape everything that follows, including how much equipment we bring and how it is wired.
- Name one owner for the outgoing feed
- Confirm publishing accounts and logins early
- Decide in advance what happens if the feed drops
Trusting the venue connection
Venue staff are usually honest when they say the internet is fast. The trouble is that speed tests measure a quiet afternoon, not a full hall with hundreds of phones joining the same network. An upload that looks generous at noon can sag badly once the doors open, and a stream that depends on it will sag with it.
Ask for a dedicated, wired connection that carries nothing but your feed, and ask what its upload speed is rather than its download speed. Many people mix the two up. Streaming needs upload capacity, and it needs headroom well beyond the bitrate you plan to send, because the connection must stay steady for the entire running time.
Where a venue cannot offer that, we plan a second route, such as a bonded cellular link, so the feed has somewhere to go if the first path wobbles. It costs more to arrange, but it is far cheaper than apologising to an audience for a broadcast that vanished halfway through a keynote.
- Test upload speed at the real event hour, not off peak
- Insist on a wired line used only by the stream
- Arrange a second route for anything that matters
Setting the encoder once and walking away
Encoding settings are often copied from a guide and never questioned. A bitrate that suits a talking head can fall apart on a stage show with fast camera moves and flashing lights. Frame rate, resolution and keyframe interval all affect how the picture looks on a phone with a poor signal, which is where plenty of your viewers will be.
The fix is a proper test with real content, not a colour bar. Run the actual cameras, graphics and a stretch of the busiest moment you expect, then watch the result on the devices your audience uses. Check it on a phone over mobile data as well as on a good monitor.
Keep a note of the settings that worked, and lock them once agreed. The most damaging changes happen in the last hour, when someone adjusts a value to fix a small problem and creates a larger one. If a setting needs to change on the day, one person makes the change and announces it to the rest of the crew.
- Test with real show content, not test patterns
- Check the result on a phone over mobile data
- Lock agreed settings and log any change
Nobody watching the outgoing feed
The gallery sees the programme output, and it is easy to assume that what the director sees is what viewers receive. It is not. Between the switcher and the audience sit the encoder, the network and the platform, and each can introduce a fault the gallery never notices: frozen frames, audio drifting out of step, a feed that has quietly stopped.
Someone must watch the stream as a viewer would, on a separate device, through the platform itself, with headphones on. That person is not the vision mixer and not the producer juggling the running order. Their only job is to confirm that the thing leaving the building is the thing people are meant to see.
This is why our streaming work includes monitoring as a named task. When a problem appears, the monitor tells the producer in plain words, and the producer decides whether to switch to a backup source or hold a graphic while it is fixed. Calm, short messages matter far more here than clever tools.
- Watch the live stream on a separate device
- Listen on headphones for drift and dropouts
- Give monitoring to one person with no other duties
Skipping the rehearsal and the fallback plan
A full technical rehearsal feels like a luxury when the schedule is tight, so it is the first thing to be dropped. Yet nearly every serious fault we have dealt with would have shown itself in a run-through: a missing cable, a laptop that goes to sleep, a platform key that had expired, a presenter whose microphone cut out when they walked to the left of the stage.
Rehearse the whole path, from camera to viewer, at the time of day the event will run. Include the awkward moments: a speaker arriving late, a video clip with its own sound, a switch to a remote guest. If something fails, write down what you did and who did it.
Then decide your fallback before you need it. A holding slide, a pre-recorded loop and a standby encoder are small things to prepare and make a failure look like a pause instead of a collapse. Agree who gives the instruction to use them, so nobody hesitates when the moment comes.
- Rehearse the full path at the real time of day
- Prepare a holding slide and a standby encoder
- Agree who calls the fallback
Leaving the client out of the conversation
A stream can run perfectly and still leave the organiser anxious, simply because nobody explained what was happening. Silence during setup reads as trouble. Clients who hear only at the end, or only when something goes wrong, tend to lose confidence in the whole operation, however sound the technical work.
I keep clients informed at each step: what has been tested, what is still open, what will be checked on the morning, and who to speak to during the show. A short message before doors open, saying the feed is live and healthy, removes a great deal of worry.
After the event, a brief note on what went well and what we would change gives the next production a better start. It also records decisions that would otherwise live only in someone's memory. Good streaming is as much about clear communication as it is about equipment, and the two support each other throughout the project.
- Agree who the client speaks to during the show
- Send a short status note before the event starts
- Record lessons while they are fresh
None of these mistakes is exotic, and none needs expensive equipment to fix. They come from leaving the stream to chance, trusting assumptions instead of tests, and letting nobody own what viewers actually see. Give the feed an owner, test it with real content at the real hour, watch it as a viewer would, and keep a fallback ready. Do those things and most streamed events run quietly, which is exactly how they should run.
