None of them are exotic. That is the depressing part.
The same seven faults keep coming back to us, and they arrive at a wedding, a Sunday service, a school match and a paid workshop in exactly the same shape. Each one waits until the event is live before it says anything, because that is the nature of the thing: nobody looks closely at a live stream until it stops behaving. We build WpStream for live streaming on WordPress, so these seven reach our inbox with some regularity.
So here is the list. What the viewer actually saw, why it happened, and the number that fixes it. There is no general advice in here about being prepared. Being prepared is not a setting.
Start with what your audience told you they saw.
| What you saw or heard | Which mistake to check |
|---|---|
| Picture breaks up under motion, then recovers | 1. Upload bandwidth |
| Soft or blocky picture the connection cannot carry | 2. Encoder settings |
| Stalls at random, at the worst moment | 3. Wifi, not wired |
| Speech distorted, hard to follow, or missing | 4. Audio afterthought |
| A fault appears first in front of viewers | 5. No test stream |
| Wrong people got in free, or buyers could not | 6. Access and payment |
| Stream goes dead, audience told nothing | 7. No fallback |
1. Upload bandwidth never measured
The picture holds beautifully until somebody moves. Then it breaks into blocks, smears, stalls, and clears itself again as if nothing had happened. No pattern. No time of day.
Almost nobody measures. The bitrate gets copied out of a guide, and the connection is tested once, three weeks early, on a quiet Tuesday morning, from a building with nobody in it.
Who tests a connection three weeks early and calls that evidence?
The only measurement worth having is taken at the hour the event actually runs, against our ingest servers rather than a generic speed test, because the generic one is measuring a route your stream will never take. OBS Project puts the starting point at 75% of upload speed, and the arithmetic underneath that is worth ten minutes of your life, once.
Under it. Not on it.
2. Encoder settings guessed
A soft, blocky picture that never sharpens, or a stream the connection cannot carry at all. Nobody checked bitrate, resolution and frame rate against the real upload rate, so all three are decorative.
The number came off a screenshot or a forum comment. And 60fps gets picked because it is twice as good as 30fps. That is the whole of the reasoning.
All three belong on a published ladder. YouTube’s live encoder guidance asks for 12 Mbps at 1080p60, 10 Mbps at 1080p30, 6 Mbps at 720p60 and 4 Mbps at 720p30. Keyframe interval: 2 seconds. Two. It is not a dial to explore, and the settings that belong beside it are equally dull on purpose.
3. Wifi instead of wired
Stalls with no pattern, at the worst available moment: the vows, the match point, the first question.
Wifi passes a speed test the way a nervous candidate passes an interview. Brilliantly, once, under conditions nobody is ever going to reproduce. Then it is asked to hold that performance for two hours in a room full of people, and it does what any of us would do.
This was never a speed argument. A fast wireless link can swing between a high rate and a very low one, and an encoder does not want a high rate, it wants one it can hold. OBS Project recommends wired over wireless for exactly that reason.
The cheapest fix on this list is a cable. Everything after the cable, getting OBS talking to your own site, is the easy part.
4. Audio as an afterthought
What the viewer gets: speech they cannot follow, distortion on the loud syllables, room echo, a hum under everything, one half of a conversation, or silence.
Video takes all the setup time because bad video is obvious in the preview window. The microphone gets plugged in and then never listened to, which makes it decoration with a cable attached.
Stereo audio sits at a 44.1 kHz sample rate. YouTube recommends 128 kbps for it and OBS Project’s own guidance says around 160 kbps, so anywhere in there is defensible. This is also the one fault on the list that settings alone will not rescue, which is where the equipment that gets audio right earns its money.
And then somebody listens to it on headphones. Before the audience has to.
5. No test stream
Whatever is wrong gets found in front of the audience, rather than in a window where it could have been fixed quietly.
A rehearsal feels like unpaid work for a single event. And the setup that behaved last time has made no promises about this time.
So the first person to discover the fault is a viewer, which is a slightly expensive way to run quality control.
What settles it is a real test broadcast, not a local preview, with the Live Statistics page open beside it. That page reports the channel state, the frame rate, the keyframe interval, the bitrate actually arriving and an incoming bandwidth graph, and it warns when one of those is wrong. Everything you needed an hour earlier, sitting there an hour earlier. The full walkthrough of the software covers the rest of that page.
6. No access or payment path decided before the event
Either the wrong people watched for nothing, or the people who paid could not get in. Both surface in the same minute, and it is the minute the event starts.
Access feels administrative next to the encoder and the audio, so it slides to launch day. It is also the only mistake on this list that comes with a bill attached.
The model gets decided first. A stream that should stay private wants a password and nothing more elaborate. A ticketed event is a different job: selling access to a live stream has its own setup, and it deserves its own rehearsal. Content valuable enough that somebody would restream it wants DRM on top, decided now rather than afterwards.
And somebody buys a ticket before the day, and watches the whole thing as a customer.
7. No fallback when one leg fails
Dead air. Not a soft picture or thin sound. Nothing at all, and an audience with no way of knowing whether waiting is worth it.
People plan for the stream working. Several parts sit between an encoder and a viewer’s screen, the streaming server and the CDN that carries it the rest of the way among them, and when one stops there is no message ready to go out.
A channel that is on but not broadcasting already shows something, either “not yet started” or “paused”, so the paused message is worth writing on the Live Statistics page early, while you are calm and nothing is on fire.
And when the encoder does drop, the remaining hours get checked before the network does. The encoder cannot tell an empty account from a dead router. Neither can you at the time, which is why the account gets checked first. Emails go out at 20% remaining and again at exhaustion, and on a paid plan you can top up and carry straight on, with nothing for viewers to do. And a channel turns itself off after a full hour with no broadcast, so a viewer count that drops to zero all at once is not an audience leaving. It is the channel.
Seven faults. Each with a number attached. Every one of them cheaper to find on a quiet afternoon than in front of an audience.
Go and find yours. There is a free trial if you have nothing to break yet.
Table of Content
