Tutorials Streaming

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

By Infinite Creation · Beginner · ~16 min

A 1960s mid-century comic book style editorial illustration showing a streaming operator watching a wall of encoders, with a bank of encoders, a phone clamped to a rig, a calibrated monitor visible in the frame.

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 recommendation for H.264 at 720p, at 30 or 60 frames per second, and 2 and 6 Mbps for AV1 and H.265. It publishes no maximum. Worth noting, because a widely repeated figure of 2500 kbps sits below the platform’s own H.264 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. At the lowest bitrates a lower resolution trades sharpness for stability, and in our test 720p scored slightly higher than 1080p at 1000 kbps. From 2500 kbps up, 1080p scored higher. 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.

Tested: resolution against bitrate, and VP8 against VP9, in FFmpeg

We tested two of the page's claims on 2026-09-29 with FFmpeg 8.1.2, scoring encodes against their source with VMAF and PSNR. The sources are generated, a test pattern with noise and a fractal zoom, so what follows is one kind of content and real footage will differ. The first three rows use x264 in a live style setup, veryfast with zerolatency and a capped bitrate, at three resolutions and three bitrates, each scaled back up to 1080p and compared with the 1080p source. The rows after the second header compare VP8, VP9 and H.264 in realtime mode on one thread, reporting quality, the bitrate actually produced and the CPU time of the encode alone. No browser or WebRTC stack was involved, and nothing was looked at.

libx264, live style, 6 s test pattern with noise	1000 kbps	2500 kbps	5000 kbps
1080p, scaled back to 1080p	80.8 VMAF, 34.7 dB PSNR	92.0 VMAF, 36.6 dB PSNR	94.7 VMAF, 37.5 dB PSNR
720p, scaled back to 1080p	81.7 VMAF, 34.2 dB PSNR	85.7 VMAF, 34.7 dB PSNR	86.7 VMAF, 34.9 dB PSNR
480p, scaled back to 1080p	76.9 VMAF, 33.0 dB PSNR	78.4 VMAF, 33.1 dB PSNR	80.0 VMAF, 33.2 dB PSNR
Realtime, 720p, one thread	VP8	VP9	H.264
fractal zoom, 1000 kbps target: VP8 / VP9 / H.264	57.0 VMAF at 1033 kbps, CPU 1.2 s	66.3 VMAF at 1213 kbps, CPU 2.2 s	54.9 VMAF at 1123 kbps, CPU 0.7 s
fractal zoom, 2500 kbps target: VP8 / VP9 / H.264	77.9 VMAF at 2586 kbps, CPU 1.3 s	78.2 VMAF at 2579 kbps, CPU 2.3 s	78.4 VMAF at 3056 kbps, CPU 0.9 s
test pattern with noise, 1000 kbps target: VP8 / VP9 / H.264	87.2 VMAF at 1011 kbps, CPU 0.8 s	82.2 VMAF at 1149 kbps, CPU 2.2 s	83.5 VMAF at 1036 kbps, CPU 0.7 s
test pattern with noise, 2500 kbps target: VP8 / VP9 / H.264	91.0 VMAF at 2533 kbps, CPU 0.9 s	89.6 VMAF at 2747 kbps, CPU 2.8 s	91.5 VMAF at 2651 kbps, CPU 0.9 s

Step 5 was half right, and now says where it holds. At 1000 kbps 720p scored 81.7 VMAF against 80.8 for 1080p, so the lower resolution scored better at the low bitrate, by a small margin of 0.9 points. At 2500 kbps 1080p pulled ahead, 92.0 against 85.7, and it stayed ahead at 5000. PSNR, which does not model what a viewer sees, ranked 1080p first at every bitrate. So "the same bitrate at a lower resolution looks cleaner" holds at the lowest bitrate here, and is not a general rule. The claim was tested down to 480p: it came last at every bitrate, 76.9 at 1000 kbps and 80.0 at 5000, which supports the page's advice to treat 720p as the floor, though this only measures fidelity to a 1080p source, not readable text.

Step 6's cost claim holds and its quality claim came out mixed, in realtime mode on this content. VP9 used more CPU than VP8 in every case, between 1.77 and 2.99 times as much. It scored higher than VP8 in 2 of 4 cases and lower in the rest. On the fractal zoom at 1000 kbps VP9 led by 9.2 points, and on the noisy test pattern at the same target it trailed by 5.0. VP9's output came to 103 to 121 percent of the target bitrate and VP8's to 101 to 103 percent, so part of any difference is rate control and not compression. The page's advice to pick VP9 when short of bandwidth may hold better in the slower encoding modes that give VP9 its efficiency, and we did not test those. In realtime the cost was certain and the benefit depended on the content.

Encode a test clip the way the live style rows were made, at 720p and 2500 kbps: ffmpeg -i in.mp4 -vf scale=1280:720 -c:v libx264 -preset veryfast -tune zerolatency -b:v 2500k -maxrate 2500k -bufsize 5000k -g 50 -pix_fmt yuv420p out.mp4

Validated. Measured 2026-09-29 with FFmpeg 8.1.2 (libx264, libvpx, libvpx-vp9, libvmaf) on generated video. VMAF and PSNR are objective scores and do not replace looking, and the sources are synthetic. CPU times are from one machine with a single thread and vary with the machine. We did not test browsers, WebRTC, hardware encoders, YouTube's published bitrates, real footage, or the symptom table. The command is the x264 setup that was measured.

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's table, read 5 October 2026, gives 720p at 30 or 60 frames per second a 3 Mbps minimum and an 8 Mbps recommendation for H.264, and 2 and 6 Mbps for AV1 and H.265. It publishes no maximum. 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 H.264 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.

Sources

YouTube Help, Choose live encoder settings, bitrates, and resolutions, read 5 October 2026. It gives 720p at 30 or 60 frames per second a 3 Mbps minimum and an 8 Mbps recommendation for H.264, and 2 and 6 Mbps for AV1 and H.265, with no maximum column. It lists H.264, H.265 and AV1 over RTMP or RTMPS and does not list VP8 or VP9, so the VP8 and VP9 comparison above is about encoder behaviour, not a YouTube option. Not checked: the 200 Mbps plan figure and the upload headroom guidance.

FAQ

Q: What bitrate should I use for a 720p stream?
A: For H.264, YouTube lists 3 Mbps as the minimum for 720p at 30 or 60 frames per second and recommends 8 Mbps. For AV1 and H.265 it lists 2 and 6 Mbps. Set yours between the minimum and the recommendation, then confirm your tested upload speed is roughly double whatever you chose. A widely repeated figure of 2500 kbps sits below the published H.264 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.