A friend messaged me last year saying his stream kept stuttering and he had already upgraded his broadband twice. He had not changed a single setting in his encoder in three years.
This is the normal shape of the problem. People blame the connection because it is the part they can see, and the actual cause is sitting in a settings panel they opened once during setup and never went back to.
The two different things people call buffering
Worth separating, because they have different causes and get discussed as though they are one issue.
There is buffering that viewers experience, where the playback stalls and the spinner appears. And there is dropped frames on the broadcaster's end, where the encoder cannot keep up and simply discards frames before they are sent.
They look similar to the person watching. They come from opposite ends of the pipeline. If your own software is reporting dropped frames, no amount of viewer-side anything will help.
Upload is not the number you think it is
The advertised upload speed on a domestic connection is a peak under good conditions, not a floor. It varies through the day, it varies with what else is on the network, and on some connection types it varies with what the neighbours are doing.
The rule of thumb that has never failed me is to set your video bitrate to about half of your measured sustained upload, not your advertised upload, and measure it at the time of day you actually stream.
People run a speed test at two in the afternoon on a quiet network, see a good number, set their bitrate to eighty percent of it, and then stream at nine in the evening when everyone in the building is watching something. Of course it falls over.
Also worth knowing: a lot of the stuttering that gets blamed on bandwidth is actually latency spikes rather than throughput. A connection can have plenty of headroom and still deliver frames unevenly if something else on the network is saturating the queue. Someone uploading a large backup in the next room will do this and will not show up on a speed test you run afterwards.
Encoding is a choice about where the work happens
Software encoding uses the processor. Hardware encoding uses dedicated silicon on the graphics card or the processor's integrated block.
Software encoding at a given quality setting generally produces better looking video at the same bitrate. It also loads the processor heavily, which matters enormously if you are streaming a game the same machine is trying to run.
The mistake I see constantly is someone running software encoding at a demanding preset while playing something intensive, then blaming the stream quality on their connection. The processor is being asked to render the game and compress the video simultaneously and it is losing.
Modern hardware encoders are considerably better than they were a few years ago. The quality gap has narrowed to the point where, for most streaming, the argument for software encoding on a single-machine setup is weak.
Resolution and frame rate interact badly
People want to stream at the highest resolution and the highest frame rate, and then set a bitrate that cannot support both.
The result is a picture that falls apart during motion, which is exactly when people are looking at it. A stream that looks fine on a menu screen and turns into a smear during action is nearly always this.
The honest trade-off is that if your bitrate is limited, dropping the resolution is usually less damaging than dropping the frame rate for anything with movement in it. A clean lower resolution reads better than a higher resolution that is starved of data.
For talking-head content the opposite applies. There is very little motion, the encoder has an easy job, and resolution is where the perceived quality sits.
Keyframe interval and the settings you should not touch
There are a handful of settings that platforms specify and that people change because they read something.
Keyframe interval is one. Platforms generally want a specific value and setting it to something else causes problems in transcoding that show up as odd artefacts or as the platform refusing to generate lower quality versions of your stream.
That last part matters more than it sounds. If the platform cannot transcode your stream, viewers on slower connections get your full-quality stream or nothing, and they will be the ones buffering. Your own connection is fine. Theirs is being handed something they cannot receive.
How I diagnose it now
First question: does the broadcasting software report dropped frames, and are they network dropped or encoder dropped? Most software distinguishes these and the distinction tells you which half of the problem you have.
Encoder dropped means the machine cannot keep up. Reduce the encoding load, switch to hardware encoding, lower the preset, or lower the resolution.
Network dropped means frames were produced and could not be sent. Lower the bitrate, check what else is using the connection, and check the connection at the time you actually stream.
Neither reported, but viewers complain? Then it is likely the viewer's end or the platform's transcoding, and the first thing to check is whether your settings are producing something the platform can process properly.
The thing that fixed it for my friend
He was streaming at a bitrate slightly above what his connection could sustain in the evening, with software encoding at a heavy preset, while running a game that used most of his processor.
Every one of those three things individually would have been survivable. Together they were not. Dropping the bitrate by a third and switching to hardware encoding fixed it in about four minutes, after two broadband upgrades that had achieved nothing.