Streaming Mistakes We See Often and How to Avoid Them

The most common mistake is planning the cameras, the stage and the running order in detail, then leaving the stream itself to the last week. A stream is a chain: camera, switcher, graphics, encoder, network, platform. Each link needs an owner and a test, and when nobody owns the chain, nobody notices that one link is weaker than the rest.

I like to start the conversation with the destination and work backwards. Which platform will carry the show? What does it accept for resolution, frame rate and bitrate? Who watches it, and on what devices? Once those answers are written down, the encoding settings, the graphics sizes and even the camera framing follow far more easily than if we guess and adjust later.

Clients are often surprised by how much of this can be settled in a short call before anyone travels to the venue.

• Name one person responsible for each link in the chain
• Confirm platform requirements before choosing encoder settings
• Decide the audience devices early, since they shape graphics

A venue may describe its connection as fast and reliable, and it may well be both on a quiet weekday morning. A full hall of phones, a busy kitchen and a crowd of guests on the same network tell a different story by evening. Speed figures quoted over the phone say little about the upload side, which is the only side a stream cares about.

We ask for a test at the same time of day as the show, with the upload measured over a sustained period rather than a single quick check. Where the result looks thin, we talk about a dedicated line or a bonded backup well before the day, because these take time to arrange.

The aim is simple: never discover the limit of the connection while the audience is watching.

• Test upload speed at the hour of the show, not at setup
• Keep the stream on its own connection, away from guest traffic
• Arrange a backup path for anything that cannot be repeated

Encoder settings are frequently copied from a previous job and never questioned. A bitrate that suits a talking head in a quiet studio can fall apart on a concert with fast cuts, haze and moving lights, where the picture is busy and the encoder has far more to describe in every second.

We set the bitrate with some headroom below what the connection can hold, so a small dip in the network does not become a visible collapse. We also run a rehearsal with real content, not a test card, and watch how the picture behaves when the lighting changes quickly.

A short rehearsal on the actual platform, viewed on an ordinary phone as well as a monitor, usually shows more than an hour of reading settings.

Lower thirds, scores and sponsor panels are designed on large monitors, then watched by most people on a small screen held at arm's length. Thin fonts, low contrast and text placed near the edge of the frame all suffer. Some platforms also overlay their own controls on part of the picture, hiding what we placed there.

We keep type larger than feels necessary, leave generous margins and check every graphic on a handset before the show. Names and titles are collected and spelled out in advance, because correcting a misspelt name live is awkward and avoidable.

Fewer graphics, held on screen for a comfortable length of time, almost always read better than a busy and constantly changing frame.

• Check every graphic on a phone before going live
• Collect names, titles and spellings ahead of the show

Inside the gallery, the programme feed looks perfect, which is exactly why it cannot be used to judge the stream. The audience sees what comes out of the platform, with its delay and its compression. A frozen frame, a muted audio channel or a stalled encoder can run for minutes while everyone in the room believes all is well.

We always place someone on a separate device, watching the public stream as a viewer would, with sound on. That person tells the producer at once if the picture stalls, the audio drifts or the stream drops, and we can switch to the backup before many viewers have noticed.

This is a modest job in terms of hours, yet it is the check that most often rescues a broadcast.

Every stream eventually has a bad moment: a cable pulled, an encoder that locks up, a platform that hiccups. The mistake is not the fault itself but arriving at it with no agreed response, so that several people propose different fixes at once while the audience waits.

Before a show we write down a short list of likely faults and who does what for each. We agree when to restart the encoder, when to move to the backup path, and what the audience sees in the meantime, perhaps a holding slate with a simple message.

Rehearsing one of these failures during setup takes ten minutes and makes the real thing feel almost routine.

• Agree the first action and its owner for each likely fault
• Prepare a holding slate and test switching to it