Tutorials Streaming

Why Your Live Stream Looks Bad, and How to Fix It

Beginner · ~16 min

Overview

A stream looking soft, blocky or frozen has one of three causes. Your computer runs out of processing power. Your connection runs out of upload bandwidth. Or your settings ask for more than either one delivers. All three produce damage looking similar on screen, so guessing which one you have wastes an evening. Work through them in the order below and you find the real cause in a few minutes. This page covers browser-based studios, where the broadcast runs in a tab. If you stream from OBS on the desktop, the companion page on dropped frames covers the encoder side in more detail.

What You Need

A real upload speed test, run on the machine you stream from and over the connection you will use
Access to your platform settings, including bitrate, resolution and any codec option
Task Manager on Windows or Activity Monitor on macOS, open during a test broadcast
A second device for watching the output, because checking your own stream on the streaming machine causes the problem you are trying to fix
An Ethernet cable, if the router sits within reach of your desk

Steps

Read the damage on screen before changing a single setting

The picture tells you where to look. Blocky squares appearing during motion, then clearing when the shot settles, mean the encoder has too few bits for the pixels you asked of it. Bitrate is the suspect. A soft, out-of-focus picture holding steady with no blocking means you are sending a low resolution, or the platform downscaled you. Video freezing while audio keeps going means frames are being lost, from processor overload or a network stall. Audio and video drifting apart points at the machine rather than the line. Match the symptom first and you skip two thirds of the work.

Test your real upload speed, not the number on your bill

Run a speed test on the streaming machine, over the connection you will use, and write down the upload figure. Consumer connections advertise download and treat upload as an afterthought, so a 200 Mbps plan often carries 10 Mbps upward or less. Test three times at the hour you plan to go live, because a shared line at 9pm behaves nothing like the same line at noon. The lowest of your three results is the number to work from.

Leave headroom, because a saturated uplink fails hard

Your stream has to fit inside your upload with room to spare. Streaming at 4000 kbps over a 4.5 Mbps line will fail. Packet headers and retransmits add roughly 5 to 10 percent on top of your video and audio, your own machine sends other traffic, and a fully saturated uplink drags your download speed down with it. Guidance runs from 30 percent headroom in controlled conditions to double the bitrate on a home connection. Target somewhere between half and two thirds of your tested upload and you land in a safe place.

Set bitrate from a platform figure, then walk it down

Start from a published number rather than a guess. YouTube lists 3 Mbps as the minimum and 8 Mbps as the maximum for 720p at 60 frames per second, recommending 6 Mbps, and recommends 4 Mbps for 720p at 30. Worth noting, because a widely repeated figure of 2500 kbps sits below the platform’s own floor for 720p. If your stream breaks up at the recommended setting, walk the bitrate down in steps of 500 kbps and watch for a full minute after each change. The first step holding steady is your setting. Halving the number in one move overshoots and costs you picture quality you did not need to give up.

Match resolution to bitrate, and hold the line at 720p

Resolution and bitrate work as a pair. A high resolution on a low bitrate produces the blocky look, because the encoder spreads too few bits across too many pixels. The same bitrate at a lower resolution looks cleaner, softer but stable. Below 720p, on-screen text stops being readable, faces lose detail on a phone, and platforms rank you against everything else in the feed. Treat 720p as the floor. If your connection refuses to carry 720p at 3000 kbps, fix the connection rather than dropping to 480p.

Pick your codec by whichever resource you are short of

Browser studios negotiate a codec with your machine, usually VP8 or VP9, and some expose the choice in device settings. VP9 compresses better, so at the same bitrate the picture holds together and low-bitrate blocking is reduced. The saving costs processing time, because VP9 encoding is heavier work than VP8. VP8 is the WebRTC default, light on both encoding and decoding, and supported everywhere. The rule follows from the trade. Short on bandwidth, pick VP9. Short on processor, pick VP8. Forcing VP9 on an already-struggling laptop makes the freezing worse rather than better.

Take work away from the processor

Encoding live video is the heaviest thing your machine does all day, and it competes with everything else running. Close other applications, and close browser tabs, because each tab holds its own render process. Quit video calls, cloud sync clients, game launchers and editing software. Inside the studio, hide participant feeds you do not need on screen, since every incoming guest video is a separate stream your machine decodes and paints on each frame. Lower your webcam capture quality too. A 4K webcam feeding a 720p broadcast makes your machine downscale every frame for no gain.

Stop watching your own stream on the streaming machine

This one surprises people. Keeping the live output open on the destination platform while you broadcast means your machine downloads the same video it is busy uploading. You pay for a second decode, a second render, and a download running against your upload on the same line. Hide the stream feed in your studio, close the platform tab, and watch the output on a phone or a second machine instead. You also get an honest view of what viewers see, delay included.

Give the network the best shot you have

Plug in an Ethernet cable. A cable removes interference, the neighbours sharing your channel, and the throughput swings of a shared wireless band, and it is the single highest-value change on this page. If wireless is your only option, use the 5 GHz band, sit close to the router, and keep off 2.4 GHz, where microwaves and wireless keyboards live. Then protect the line for the duration. Pause cloud backup and system updates, stop downloads, and ask the household to hold off on 4K video while you are live.

Rehearse at your real settings before it matters

Run a private or unlisted broadcast for ten minutes at the exact settings you plan to use, with the same guests, the same camera and the same overlays. Watch it on another device. Keep your platform health dashboard and your system monitor open on the side. A stream degrading after fifteen minutes rather than at the start is a thermal problem, and only a rehearsal of real length finds one.

Pro Tips

Change one setting at a time and watch for a full minute. Encoders take time to settle, and stacking three changes leaves you unable to tell which one helped.
Laptops throttle when hot. A stream starting clean and falling apart twenty minutes in points at heat rather than settings. Raise the machine off the desk so air reaches the underside.
Plug the laptop in. Most machines cap processor performance on battery, and a live broadcast is the worst moment to find out.
Check hardware acceleration is turned on in your browser settings. Turned off, the browser encodes in software, and this is a common hidden cause of a pinned processor in a browser studio.
Wired guests produce better streams than you do. Send your guests this page before the broadcast, because one guest on weak hotel Wi-Fi degrades the recording of everybody.
Run the speed test again at your broadcast hour rather than trusting a morning result. Shared connections lose upload capacity in the evening.
Keep a written note of the settings working on your machine. Rebuilding them under pressure five minutes before a live start is how good broadcasts go wrong.

Knowledge Base

What You'll Learn

The table below turns a symptom into a first move. The sections after it cover the two places where common advice is wrong, and where the numbers come from.

Symptom, cause, first move

What you see	Usual cause	First move
Blocky squares during motion, clean when still	Bitrate too low for the resolution	Raise bitrate, or lower resolution to 720p
Soft and out of focus, steady, no blocking	Resolution too low, or platform downscaled you	Check output resolution is 720p or above
Video freezes, audio keeps playing	Dropped frames from processor or network	Check the system monitor first, then upload speed
Quality fine at the start, degrades after 15 minutes	Thermal throttling	Improve airflow, plug in the power adapter
Audio and video drift apart	Machine overloaded	Close applications and tabs, hide unused feeds
Only one guest looks bad	The guest’s own connection or machine	Fix it at their end, not in your settings
Stutters every few minutes, otherwise clean	Wi-Fi interference or a background transfer	Switch to Ethernet, pause cloud sync

Two machines split the processor, not the connection

A piece of advice going around says to split the work across two computers when your upload sits below 2.5 Mbps, running the conference on one and the broadcast on the other. The reasoning behind the split is sound. The threshold attached to it is not.

Two machines on one connection share the same uplink. Your total upload is unchanged, and the router still has the same capacity to hand out. If bandwidth is what you lack, adding a second computer to the same network solves nothing, and you now have two machines competing for the same scarce resource.

Splitting machines is a fix for a processor problem. Running a conference with several guest videos and encoding a broadcast are two heavy jobs, and giving each one its own machine works well. Do it when your system monitor shows a pinned processor while your speed test looks healthy.

There is one case where the split does buy bandwidth. Put the second machine on a separate connection, such as a mobile hotspot, and the two workloads stop sharing an uplink. Now you have added capacity rather than divided it.

Where the bitrate numbers come from

Platforms publish ingest guidance, and starting from theirs beats starting from a forum post. YouTube lists 720p at 60 frames per second as a 3 Mbps minimum and an 8 Mbps maximum, recommending 6 Mbps, and recommends 4 Mbps for 720p at 30 frames per second. Higher resolutions and frame rates raise every one of those figures.

Two things follow. First, a widely repeated recommendation of 2500 kbps as the floor for high quality sits under the platform minimum for 720p, and setting it there is how people end up with blocking they blame on their camera. Second, these are ingest figures rather than delivery figures. The platform re-encodes your stream into a ladder of qualities for viewers, so what you send is the ceiling on what anybody receives. Sending a soft picture guarantees every viewer gets a soft picture.

Frame rate costs bits as surely as resolution does. A 720p broadcast at 30 frames per second and a clean picture serves an audience better than 1080p at 60 breaking up under motion. Pick the setting your connection sustains on its worst evening.

The order to work in

Read the symptom. Sixty seconds of looking narrows three causes to one.
Measure the connection. Speed test on the streaming machine, at the streaming hour, three runs.
Measure the machine. System monitor open during a test broadcast, watching the processor figure.
Change one thing. Bitrate, resolution, codec or load, one at a time, a minute of watching after each.
Rehearse at full length. Ten minutes minimum, on a second screen, before the broadcast matters.

Skipping the two measurement steps is what turns a fifteen-minute fix into a lost evening of changing settings at random.

Where This Fits

This sits under OBS Studio for Beginners, the pillar for livestreaming on this site, which covers scenes, sources, encoding and audio routing end to end. Why Your Livestream Keeps Dropping Frames is the companion page for desktop encoder problems, where your software reports encoding lag and network drops separately. How Livestream Bitrate Ladders Work explains what the platform does with your stream after you send it, and Multistreaming covers sending one broadcast to several destinations without multiplying your upload.

FAQ

Q: What bitrate should I use for a 720p stream?
A: YouTube lists 3 Mbps as the minimum for 720p at 60 frames per second and recommends 6 Mbps, with 4 Mbps recommended at 30 frames per second. Set yours inside those ranges, then confirm your tested upload speed is roughly double whatever you chose. A widely repeated figure of 2500 kbps sits below the published minimum for 720p.

Q: Why does my stream look blocky only when I move?
A: The encoder has too few bits for the pixels you asked of it. A still shot compresses easily, and motion forces the encoder to describe a changing frame with the same budget. Raise the bitrate, or lower the resolution and keep the bitrate where it is.

Q: Should I choose VP8 or VP9?
A: Pick by whichever resource is scarce. VP9 compresses better and looks stronger at low bitrates, at the cost of heavier encoding work. VP8 is lighter on the processor and supported everywhere. Short on bandwidth, choose VP9. Short on processing power, choose VP8.

Q: Does watching my own stream while broadcasting hurt anything?
A: Yes. Your machine downloads the same video it is uploading, which adds a decode job and puts a download alongside your upload on one line. Watch on a phone or a second computer instead.

Q: My stream is fine for fifteen minutes, then falls apart. Why?
A: Heat. Sustained encoding pushes a laptop into thermal throttling, and the machine reduces its own performance to cool down. Improve airflow under the machine, plug in the power adapter so the processor is not capped by battery mode, and rehearse at full broadcast length rather than for two minutes.

Q: Will a second computer fix my low upload speed?
A: Not on the same connection. Two machines share one uplink, so your total upload is unchanged. Splitting machines fixes a processor bottleneck. It buys bandwidth only when the second machine sits on a separate connection, such as a mobile hotspot.