Good live video is usually won before you hit go live: by making the right choices about bandwidth, audio, framing, and pacing. The best tips for streaming are the ones that remove failure points, not the ones that add more gear. I’m focusing on the parts that actually change viewer experience, whether you are broadcasting a webinar, a product demo, or a face-to-camera session.
What matters most before you go live
- Match the format to the content. Fast motion, talking heads, and panel sessions need different settings.
- Leave upload headroom. A stream that uses all available bandwidth is one small network wobble away from trouble.
- Fix audio before visuals. Clear speech keeps viewers longer than extra sharpness.
- Keep the frame simple. Good light and clean composition matter more than expensive gear.
- Use a run-of-show. A timed structure prevents awkward gaps and rushed endings.
- Test the whole chain. Rehearsal catches the problems that settings menus hide.
Choose settings that match the job
The first decision I make is the target format. A live stream for a long interview, a fast gaming session, and a product demo do not deserve the same settings, because motion, text, and audience expectations are different. YouTube’s current guidance still puts 1080p streams around 8-12 Mbps and 720p around 5-7.5 Mbps, while OBS’s connection advice is to keep plenty of upload headroom and leave roughly 25% unused. I treat those numbers as a ceiling, not a target; a cleaner 30 fps stream usually beats a choppy 60 fps one.
For compatibility, I usually stay with H.264 video and AAC audio unless I have a specific reason to do otherwise. A codec is simply the compression format your encoder uses before the video goes out, and in live broadcasting, safe and predictable often matters more than clever.
| Scenario | Practical starting point | Why it works |
|---|---|---|
| Talking-head session | 720p30 or 1080p30 | Readable picture with lower network and CPU pressure. |
| Gaming or fast motion | 1080p60 | Smoother movement, but only if bitrate and encoder headroom are there. |
| Webinar or training | 1080p30 | Text and faces stay clear without wasting bandwidth. |
| Mobile-first vertical live | 9:16 frame | Fits phone viewing better when the content is close and conversational. |
If your machine struggles, hardware encoding is usually the first sensible trade-off because it preserves CPU headroom for scenes, browser sources, and the game itself. Once the target is realistic, the next question is whether your connection can actually hold it.
Protect your connection before you worry about bitrate
Upload speed is only useful if it is stable. In the UK, I would not trust a speed test from midday if the stream starts at 7 p.m., because evening congestion and shared home traffic are what usually expose weak setups. I prefer wired Ethernet whenever the broadcast matters, and I keep background syncing, cloud backups, game updates, and large file uploads turned off while I’m live.
- Plan for the stable upload number, not the headline figure from your fibre package.
- Keep your live bitrate well below total upload capacity so the stream survives small spikes and packet loss.
- Test at the same hour you plan to broadcast, because network conditions change across the day.
- Have a fallback route ready, such as a 4G or 5G hotspot, if the main line becomes unreliable.
- Avoid VPNs and unnecessary network tools during the broadcast unless you know they are not adding delay.
If a line can hold 20 Mbps up reliably, I would still build around something like 10-14 Mbps total output, not 18 or 19. That spare capacity is what keeps a stream from breaking the moment someone else in the house starts a big upload. Once the connection is under control, audio becomes the clearest upgrade you can make.
Get the audio right first
I rarely see a stream saved by better graphics if the voice sounds thin, noisy, or delayed. A good microphone placed close to the mouth does more than an expensive camera sitting across the room. I usually aim for clean peaks around -6 dBFS, which simply means the signal has room before distortion, and I keep stream audio at a sensible level so speech stays natural instead of compressed and harsh. For most voice-led broadcasts, 128-160 kbps AAC is more than enough.
- Use a dynamic mic in echoey or noisy rooms because it tends to reject more background sound.
- Keep the mic 10-20 cm from your mouth and use a pop filter so plosives do not hit the capsule.
- Listen on headphones so you catch hiss, fan noise, or echo early.
- Switch off speaker monitoring unless you need it for a specific reason.
- Treat the room with curtains, rugs, or soft furniture if it sounds hollow.
I would rather hear a slightly dry voice than a roomy one, because dry speech remains intelligible on mobile speakers and cheap earbuds. After the voice is clean, the frame has to do the rest of the work without distracting from it.

Frame and light for clarity, not perfection
I want the picture to look intentional, not cinematic. Eye-level framing, a clean background, and one soft front light are usually enough to make a stream feel polished, especially on mobile where small details disappear fast. If you rely on daylight, remember that UK weather and cloud cover can change the look of a room in minutes, so I prefer a controllable lamp or panel light for regular broadcasts.
- Keep the lens at eye level unless you have a clear creative reason not to.
- Leave a little space above the head and avoid cutting through the chin or forehead.
- Use one soft key light at about 30 to 45 degrees from the face.
- Separate yourself from the background by a small amount so the image has depth.
- Use the vertical frame only when the content is built for it, not just because it is trendy.
A vertical layout can work well for face-to-camera clips and product demos, but it is less forgiving for shared screens and wide shots. Once the visual setup is clear, the live session itself needs structure so it does not drift.
Use a run-of-show to keep the broadcast moving
A run-of-show is just the timed sequence of what happens on screen, and it keeps a live broadcast from wandering. When I build one, I write the opening, the main blocks, the audience prompts, and the closing in order so nobody has to improvise the structure mid-stream. That becomes even more important when guests, presenters, or moderators are involved, because everyone needs to know who speaks, when, and for how long.
- Open with a short holding slide or cold open that gives late arrivals a moment to settle.
- Say the topic, the promise, and the timing in the first minute.
- Break the content into blocks of 8 to 15 minutes so you can reset attention.
- Assign chat moderation, link posting, and tech support to someone other than the presenter.
- Close with a clear next step, whether that is a signup, replay, or follow-up piece.
If the stream is interactive, I also plan two or three places where I can read chat without derailing the main point. That small bit of structure usually matters more than another overlay or animated transition, and it leads straight into the last piece of the puzzle: testing.
Test, monitor, and recover when something slips
Testing is where I look for failure before the audience does. I do at least one rehearsal with the full scene stack, camera, mic, overlays, and any remote guests, and I record locally at the same time so I can check what actually happened rather than guessing from a live dashboard. If something looks off, I change one variable at a time; that is slower in the moment, but it stops me from chasing the wrong fix.
| Problem | What it usually means | Fast fix |
|---|---|---|
| Dropped frames | The upload path cannot keep up | Lower bitrate by 200-500 kbps, close background uploads, and stay on Ethernet. |
| Audio echo | Monitoring is open somewhere | Use headphones, mute extra sources, and check for duplicate mic inputs. |
| Blurry motion | Too much motion for the bitrate | Drop to 30 fps or lower the resolution. |
| Lip-sync drift | Device clocks or capture delays do not match | Recheck sample rates and add a small audio delay if needed. |
When the stream health graph starts dipping, I do not wait for it to recover on its own. I lower bitrate in small steps, close anything that is sending data, and if necessary I switch to a safer preset rather than trying to rescue a perfect spec on an unstable line. Low-latency modes can help chat feel live, but they leave less buffer, so I only use them once the network is already steady.
The five-minute preflight I would use before going live
The most useful preflight is short enough that you can repeat it every time:
- Check Ethernet or hotspot backup before opening anything else.
- Confirm the microphone, camera, and scene order.
- Mute desktop audio you do not want viewers to hear.
- Start the local recording before you go live.
- Read the first 30 seconds of your script aloud once.
After that, I leave myself one minute of silence to catch mistakes before the audience arrives. The stream will not be perfect, and it does not need to be; what viewers remember is whether the picture was clear, the sound was easy to follow, and the host seemed in control.