Live streaming and webinar production

What this actually solves

An organiser about to run a live event is not thinking about production values. They are thinking about the one outcome they cannot recover from.

That is the correct instinct. A company puts months and a serious budget into an annual conference, invites its customers, briefs its executives, and the entire public-facing part of it runs through a single stream. If that stream stutters, freezes or drops out, no amount of good camera work compensates. Nobody watching remembers a well-framed shot. Everybody remembers the buffering.

So the honest framing of this service is that you are buying insurance with a picture attached. The camera work, the switching and the graphics are the deliverable. The redundancy, the rehearsal and the local recordings are what you are actually paying for.

There is a second, quieter reason people buy it, which is that a live event is an expensive way to reach the number of people who show up live. The recording, the transcript and the clips extend that reach for weeks. Treating them as part of the production rather than an afterthought is usually where the return comes from.

How the work runs

1. Scope and run of show. Every segment in order with timings, who is on screen, which graphic is up, who cues what, and what happens if a speaker overruns. This document is the production — on the day, everyone works from it. Half a day to a day.
2. Technical recce. For a physical event, the room itself — measured upload speed on a wired connection rather than the venue's claim, power and where it fails, existing lighting, and whether the house audio can be taken as a clean feed rather than picked up off a speaker. For a remote webinar, the same checks against every presenter's setup. Half a day.
3. Graphics build. Lower thirds, titles, a holding screen for before you go live and during breaks, slide templates, and any sponsor or brand furniture. All prepared and loaded into the switcher in advance, because building anything during a live show is not possible. One to three days.
4. Full rehearsal on the actual equipment. Same cameras, same encoder, same stream key, same graphics, streamed privately end to end. Not a discussion, not a partial test — the whole chain running as it will run. Two to three hours, at least a day before.
5. Show day. Set up and soundcheck with real time built in before doors, then the show itself — switching between cameras, calling graphics, watching the encoder's health, and monitoring the outbound stream on a separate connection so you are seeing what the audience sees. The full event day, with call time around three hours ahead of the first segment.
6. After the event. Local recordings collected and checked, the clean recording edited, transcript produced, a written summary for attendees, and short cutdowns of the strongest moments. Two to five days.

Run on OBS Studio or vMix for software switching, a Blackmagic ATEM Mini where a hardware switcher is the more reliable choice, capture cards for camera inputs, and StreamYard or Restream where a browser-based setup genuinely covers the job.

What moves the price

This is quoted at $300–$5,000/event and priced per event rather than by the day, because the cost sits in the preparation rather than in the running time.

How many cameras and how many hours. A single-camera webinar and a three-camera conference day are different productions with different crew and different setup windows. Duration matters because setup and derig are largely fixed regardless of whether the show runs for one hour or six.

Whether it is in a room or on a platform. A physical venue brings cabling, power, audio capture, lighting and travel. A remote webinar removes all of that and sits at the lower end of the range.

How much of it has to exist afterwards. Streaming it and being finished is one scope. Streaming it, capturing clean isolated recordings, and producing a full post-event package of transcript, summary and clips is another — and it is the part most likely to be worth more than the stream.

What usually goes wrong

The upload speed is assumed rather than measured, and there is no second connection. Somebody tests the wifi at nine in the morning in an empty hall and declares it fine. At two in the afternoon the room is full, every phone is on the same network, and the encoder starts dropping frames. Bandwidth is measured on the actual connection that will carry the stream, with real headroom above the bitrate, and a mobile failover is configured and tested before anyone goes live.

There is no full rehearsal on the real equipment. Each individual component was checked and the chain as a whole never was. The capture card is fine, the camera is fine, the graphics are fine, and the combination drops the audio the moment the second source is switched in. Anything running live for the first time in front of an audience is a coin toss, and rehearsal is the only way to convert unknown failures into known ones.

Nothing is recorded locally, so the only copy is the stream. When you want cutdowns the following week, all that exists is a compressed platform recording of a mixed programme — one flattened angle, at whatever quality survived transmission, with no way to re-cut. Every camera records to its own card for the whole show, independently of what the switcher is doing, and that is what any usable edit afterwards is built from.