Streaming Client Events as an AV or Event Production Company

A client who books you for a conference, a product launch or a gala is buying more than cameras. They are buying the certainty that people who cannot be in the room will still see a clean, on-time programme. This guide walks you through the decisions an event or AV production company makes when it adds a live stream to a job, from the brief and the venue check to the backup feed, the language tracks and the hand-over. Each step explains the choice, the tradeoff and the check that tells you it worked.

Start with a written brief

Before you quote the job, agree with the client in writing what the stream includes, who watches it, where it appears and what happens to the recording afterwards. These four answers drive your crew size, your bandwidth needs and your liability. A stream for the staff of one company is a different job from a public launch, and a vague brief lets the scope grow after the fee is fixed. Ask the client to sign a one-page summary and keep it with your run sheet.

Add the unglamorous items too. Who approves the running order? Who may stop the stream if a speaker goes off script? Who owns the recording, and for how long may you keep a copy? You do not need legal language for this, but you do need a named person on the client side who answers within minutes on the event day, because a decision that waits for an email chain is a decision made too late.

Check the venue and the connection

Ask the venue for a technical rider and read it before you visit. The rider tells you where the house audio desk sits, what power is available, where cables may run and which network the venue offers. Then measure your upload speed at the time of day the event runs, not on an empty afternoon. A hall that is quiet in the early afternoon can be saturated in mid-morning, when many attendees arrive and open their phones.

Reserve a wired connection for the stream that is separate from the network the attendees use on their phones. Wireless networks share capacity with everyone in the room, and your encoder cannot negotiate for its share. If the venue cannot provide a separate line, bring your own, for example a bonded cellular unit or a second business line, and treat the venue network only as the last fallback. Test both paths while the room is empty and again when it fills, and write the results in the run sheet.

Choose your transport protocol with the route in mind. RTMP is widely supported and easy to configure, which makes it a sensible default for a stable wired link. When the feed leaves a venue with an unstable network, choose SRT, because it recovers lost packets better than RTMP over a long or busy route. The tradeoff is compatibility, so confirm that your encoder and your receiving platform both support SRT before the event, and keep an RTMP profile ready in case one of them does not.

A simple failure check belongs here. Send a test feed for the length of a typical session at the event's time of day, watch the dropped-frame counter in your encoder and note each stall. If the counter climbs while the room fills, you have found the problem on a day when you can still change the plan.

Build redundancy that survives one failure

Run a second encoder on a separate computer and, where possible, on a separate connection, so one failure does not take your client's event off air. A single laptop that handles capture, encoding and slides is a single point of failure, and a software update, an overheated processor or a loose cable will find it. Feed both encoders from the same output of your video switcher, and decide before the event which one is primary and who has the authority to switch.

Redundancy only helps if you rehearse the switch. Pull the cable on the primary encoder during the test and time how long a viewer would see a frozen or black picture. Tell the client what to expect, because a short interruption that you announced is an incident you managed, while one you did not mention is a complaint.

Give your stream its own audio mix from the house desk, because levels that work in the room rarely work for remote viewers. The room mix is shaped for loudspeakers: a quiet presenter is boosted and applause is lifted, so the result sounds unbalanced on headphones. Ask the venue engineer for a dedicated output, combine it with the presenter microphones and any remote guests, and monitor it on headphones for the whole event. If you only get the room feed, write that limit into the brief.

Plan languages, destinations and the client's look

When the audience speaks more than one language, book interpreters with their own audio feeds early, because finding them takes longer than any technical setup. Interpreters need a booth or a quiet corner, a clean feed of the floor language, a view of the stage and a return channel to your crew. Decide which languages the stream carries, who is responsible for each, and how you label them for viewers, then test each language track end to end on a device outside the venue.

Each added language is another audio signal to route, monitor and hand over, so weigh the benefit against the size of your crew. For a small audience in a secondary language, captions or a written summary may serve better than a live track. Ask the client for the real audience split instead of a guess before you promise tracks you cannot staff.

Decide with your client whether the stream appears on their website, on social platforms or on both, and send one feed to every destination instead of running several encoders. A single feed means a single point to monitor, and the picture, sound and timing match everywhere. Separate encoders for each platform multiply your risk and your bandwidth use. Ask the client for the platform accounts and stream keys early, keep the keys private, and test each destination with a short private broadcast before the event.

A stream on the client's own website has a clear advantage: the audience stays on their page, with their branding and their registration. Social platforms give reach and discovery but follow their own rules about rights, music and moderation. If the content is meant for invited guests only, think twice before posting it on a public platform, and put that rule in the written brief.

Keep the client's look on screen with their own holding slide and lower thirds, prepared and approved before the event day. Collect the logo files, fonts and colours in the formats your graphics software needs, then send a proof of each title and the holding slide for written approval. Misspelled names of executives are a common error, so ask the client to confirm each spelling against the speaker list and keep that list open at the graphics desk.

Rehearse and watch like a viewer

Run a full rehearsal with the speakers' slides, the presenters' microphones and any remote guests no later than the day before, so you find problems while there is still time to fix them. Use the real laptops, the real adapters and the real network path, because a rehearsal on a different setup proves very little. Include the awkward cases: a speaker who changes slides with a clicker, a guest who joins late and a video clip with sound.

Write down each problem the rehearsal reveals, assign an owner and recheck it on the morning of the event. If a remote guest connects from an office with a strict firewall, you want to learn that in the rehearsal and not when the host introduces them. Give remote guests a short written instruction and a named contact, and ask them to join well before they are due on air.

Name one person on your crew who watches the stream as a viewer would, on a phone outside the venue network, for the whole event. This person does not touch the equipment. Their job is to report what the audience experiences: sound that drifts out of sync, a slide that is unreadable on a small screen, a long delay or a frozen picture. The control room sees the source, while the viewer sees the result after encoding, transport and playback, and the two can differ a lot.

Agree on a simple way to report, such as a dedicated chat channel with short messages like audio low or slide unreadable, and make the operator acknowledge each one aloud. Expect the viewer to see the programme some seconds after the room does, and warn the client's presenters so they do not react to a question that was already answered.

Hand over the recording and a report

Hand over the recording and a short report of the audience and any incidents after the event, because that report is what wins your next booking. Keep it honest and brief: when the stream started and ended, how many people watched at the peak, what went wrong, how long the fix took and what you would change next time. Clients rarely see the work behind a smooth event, so the report makes it visible.

Return to the written brief when you deliver. Confirm that the recording goes where the agreement said, in the format the client expected, and that anything the agreement says you delete is deleted, with a note saying so. Close the job with a short call, ask what the client would like to see different and add the answers to your checklist for the next event.

A client event stream succeeds on preparation, not on equipment. Write the brief, test the venue connection at the right hour, duplicate the parts that can fail, settle languages and destinations before the day, rehearse with real material, watch as a viewer and report afterwards. These steps cost little compared with a stream that drops during the keynote, and together they turn a one-off job into a repeat client.