What Actually Happens Between Your Event and the Viewer's Screen

Almost every enquiry about streaming begins with the same worry: if we hire you, what exactly will you be doing while our event is on? It is a fair question, because from the audience's side a stream looks like a single thing. A picture appears, sound comes with it, and nobody sees the chain behind it.

In practice a stream is a series of handovers. Cameras feed a vision mixer, the mixer feeds graphics and audio, the programme goes to an encoder, the encoder sends a signal over a network connection, and a platform passes it to viewers. Any one of those links can fail quietly, which is why somebody has to watch each of them.

I am Oliver Hartley, and I direct many of our shows. This note walks through the chain in the order a signal travels, so you can see where the work sits and what we need from you at each point.

The first stage is the one people recognise. Cameras are placed and cabled, checked for exposure and colour against each other, and brought into the mixer. A vision mixer then chooses which source goes out and when, working from the running order and the director's calls on talkback.

For a streamed event this stage is no different from a broadcast gallery, and it should not be treated as a lesser job. A stream that cuts late or holds a wide shot too long feels amateur regardless of how clean the video is.

What we ask of you here is simple: a running order that is close to final, and a chance to see the stage before the audience arrives. Camera positions are far easier to agree with a venue contact on site than by email the night before.

• Camera positions agreed with the venue
• Running order shared before the rehearsal
• Named contact on site who can approve changes

Once the picture is cut, it needs everything that makes it look finished. Name straps, titles, a sponsor slate or a holding screen are added at the mixer or in a graphics machine. Audio arrives separately, usually as a feed from the front-of-house desk, and has to be matched to the picture so lips and sound stay together.

This is where small misunderstandings cause the biggest delays. If the spellings of names arrive an hour before doors, someone is typing under pressure. If the audio feed is a room microphone rather than a proper mix, the stream will sound like a recording made from the back row.

We would rather agree the audio source and the graphics text early, even in rough form, and refine from there.

The programme then reaches the encoder, which compresses it into a signal the internet can carry. Tom Fenwick, our streaming engineer, chooses the settings with the destination platform and the available upload speed in mind. A higher quality setting is no use if the venue connection cannot sustain it for the whole show.

This is the single most common point of failure, and it is usually the least visible beforehand. Venue wifi that works well for a few phones can collapse under a continuous upload. We ask for a wired connection with a known upload speed, and for a backup route where the event matters enough to justify one.

Tom tests the link at the venue before the rehearsal, not during it, so that any problem is found while there is still time to solve it.

• Wired connection preferred over wifi
• Upload speed confirmed at the venue itself
• Backup route agreed where the event allows

The last link is the platform you have chosen. We set up the stream key, the event page and the start time with you, and send a test signal beforehand so nothing is discovered live. During the show someone watches the stream as a viewer would, on a separate device, because what leaves the building is not always what arrives.

Monitoring is the part clients tend to underestimate. It means checking the outgoing picture, the sound, the delay and the platform's own health indicators throughout, and being ready to switch to a backup if the signal drops. That person is not cutting the show or directing it.

If something does go wrong, we tell you plainly what we see and what we are doing about it, rather than leaving you to find out from the comments.

You do not need technical language to start. Tell us the date, the venue, how long the event runs, how many people you expect to watch, and which platform you want to use. If you already have cameras, a switcher or an encoder, say so, and we will work around them instead of duplicating them.

Tell us also who owns the rights to the content and whether anything in the show, such as music or archive material, may be blocked by the platform. That is better settled before the day than while the stream is live.

From there we send a written quotation, agree the schedule and arrange a technical check at the venue. Each stage in the chain above gets an owner, and nobody finds out on the night that a link was assumed to be someone else's.

• Date, venue, duration and expected audience
• Chosen platform and any existing equipment
• Rights questions for music or archive material