# What the warning actually measures
OBS tracks three different kinds of frame loss, and it names them differently on purpose. The labels in the Stats panel are exact strings in the application's locale file, and they are worth reading literally because each one points at a different piece of hardware[2].
| Stats panel label | What it means | Where the bottleneck is |
|---|---|---|
| Skipped frames due to encoding lag | The encoder did not finish a frame inside its time budget | Encoder (CPU or GPU encode block) |
| Frames missed due to rendering lag | The GPU could not composite the scene in time | GPU (compositing) |
| Dropped Frames (Network) | Encoded frames never reached the server | Upload path / connection |
The “Encoding overloaded” toast is tied to the first row only. It is driven by the skipped-frame counter and nothing else. Not by network drops, not by rendering lag, and not by any reading of processor utilisation. That single fact resolves most of the confusion around this message, because the fix lists people reach for are usually aimed at the wrong row.
A skipped frame has a precise meaning. Every output frame has a deadline set by your frame rate: at 60 fps that is one frame every 16.67 milliseconds, at 30 fps every 33.3 ms. If the encoder is still busy with the previous frame when the next one arrives, the new frame is discarded rather than queued, because a live encoder that falls behind can never catch up. The discard is counted, and it is that count the warning watches.
So the question the warning answers is not “how busy is your computer?” It is “did the encoder miss its deadline, and how often?” Those two questions have very different answers on a modern multi-core machine, which is the whole reason this page exists.
# The exact trigger, from OBS's source
Almost every article on this subject describes the warning qualitatively: it appears “when your system cannot keep up”. That is true and useless. The actual condition is a two-line check in the status bar code, it runs on a fixed timer, and reading it tells you more in ten seconds than a list of settings tweaks will[1].
int skipped = video_output_get_skipped_frames(obs_get_video());
int total = video_output_get_total_frames(obs_get_video());
skipped -= startSkippedFrameCount;
total -= startTotalFrameCount;
int diff = skipped - lastSkippedFrameCount;
double percentage = double(skipped) / double(total) * 100.0;
if (diff > 10 && percentage >= 0.1f) {
showMessage(QTStr("HighResourceUsage"), 4000);
...
}
lastSkippedFrameCount = skipped;Three things in that snippet matter, and none of them are widely reported.
- It runs once per second. The function containing this check is wired to a refresh timer started with
refreshTimer->start(1000), a 1000 ms interval. Sodiffis the number of frames newly skipped within the last one second, not since you went live. - Both conditions must hold. The
&&is doing real work. A slow, steady trickle of skipped frames will push the cumulative percentage above 0.1% but never produce eleven in one second, so no warning. A single violent one-second stall on an otherwise perfect session may cleardiff > 10but not the percentage. You need both. - The percentage is cumulative, not instantaneous. It is total skipped over total frames since the counters were baselined, meaning the whole session so far. It does not decay. Once you are above 0.1% for the session, you stay above it, and the percentage condition is effectively satisfied for the rest of the stream.
It is worth putting numbers on how low the bar is. At 60 fps, 0.1% of frames is roughly one frame in a thousand, or about one frame every sixteen seconds. Over a three-hour stream that is a few hundred frames out of some six hundred thousand. Almost nobody notices that watching a stream. The burst condition is harsher: more than ten skipped frames inside one second, at 60 fps, means roughly one frame in six vanished during that second. Severe, but it only has to happen once.
The warning does not describe a sustained state. It describes a single second that went badly, on a session that has already accumulated a trace of trouble. Neither of those shows up in an averaged CPU reading.— Derived from obs-studio status-bar source, verified 3 Sep 2026
The message string itself is fixed, which is why it is so unhelpfully generic: HighResourceUsage="Encoding overloaded! Consider turning down video settings or using a faster encoding preset."[2] OBS is not diagnosing your machine when it says that. It is printing one hard-coded sentence in response to one numeric condition.
# Why a 30% CPU reading proves nothing
Now the paradox dissolves. There are three independent reasons a low processor reading is perfectly compatible with a skipped-frame burst, and on most machines more than one is in play.
1. Averaging across cores
The number in Task Manager is an average across every logical processor, sampled over a window of roughly a second. On a 16-thread machine, one thread pinned at 100% while the rest idle reads as about 6%. Software encoding is the classic case: x264 parallelises well, but the critical path for any individual frame is still bounded, and when a frame overruns its deadline it does so regardless of how much idle capacity sits on other cores. Our processor guide for streaming covers why core count alone is a poor predictor of encoding headroom.
The practical move is to stop looking at the aggregate figure. Open Task Manager, go to the Performance tab, right-click the CPU graph and choose Change graph to → Logical processors. You are looking for one or two columns pegged while the rest are calm. That pattern is invisible in the headline percentage and it is the signature of a per-thread bottleneck.
2. Averaging across time
This one is subtler and it is the reason the paradox is so persistent. Task Manager updates roughly once a second and shows you a mean over that window. OBS's trigger needs a burst that lasts part of one second. A 200-millisecond stall (a shader compiling, a scene collection loading a browser source, Windows scheduling something unhelpfully, a game streaming assets from disk) can skip a dozen frames and still leave the one-second average almost unchanged. You are comparing a peak detector against a smoothing filter and concluding the peak detector is broken.
3. The encode may not be on the CPU at all
If your encoder is NVIDIA NVENC, AMD AMF or Intel QuickSync, video compression runs on a dedicated block of silicon on the GPU, not on your processor cores. OBS's own tooltip is blunt about it: hardware encoding “eliminates most CPU usage”[2]. In that configuration a low CPU reading is not evidence of anything. It is the expected result, and it would be low whether or not you had a problem.
There is a corollary that contradicts the most common piece of advice on this topic. “Just switch to NVENC” is a genuinely good suggestion when a single CPU thread is the constraint. It is actively counterproductive when your GPU is already the constraint, because it moves the encode onto the component that is out of headroom. Which of the two applies to you is a question you can answer in about a minute, and the next section is how.
# The counter is not scoped where you think
One more piece of behaviour explains a large share of the confusing cases, and it comes from how the counters are baselined in the library rather than the interface[4].
Rendering lag and network drops are tracked per output: OBS records a starting value when a given output begins and reports the difference. Skipped frames are different. They are counted on the shared video pipeline, and that pipeline's counter is reset only when the first encoder attaches after every encoder has stopped. It is then logged when the last encoder detaches.
- Streaming and recording share one skipped-frame counter. They both draw on the same video pipeline. Frames skipped while you were recording are the same frames counted against your stream.
- Starting a second output does not reset it. If you begin recording, stream for an hour, then stop the recording, the counter has been accumulating across the whole envelope, and it clears only once nothing is encoding.
- A rough pre-stream period counts. Time spent with an encoder active before your real content began is inside the same accumulation window.
Set that alongside the cumulative percentage from the previous section and a familiar scenario resolves itself. You test your scenes, something stutters briefly, you fix it, you go live. Twenty minutes into a perfectly healthy stream the warning appears after one trivial hiccup, because the session-long percentage never went back below 0.1%. Nothing is currently wrong. The counter is simply carrying history. If you record locally as well as stream, our local recording guide covers the settings that keep the second output from competing with the first.
# Diagnose it in ninety seconds
Two instruments, both already installed. Do these in order and do not change any setting until you have finished, because changing settings mid-diagnosis destroys the evidence.
During the stream: the Stats dock
Open View → Docks → Stats. Ignore everything except three rows: Skipped frames due to encoding lag, Frames missed due to rendering lag, and Average time to render frame[2].
| What you see | What it means | Where to act |
|---|---|---|
| Skipped climbing, missed flat | Encoder cannot hit the deadline | Encoder settings or encoder choice |
| Missed climbing, skipped flat | GPU cannot composite in time | Cap game FPS, simplify scenes |
| Both climbing | GPU is saturated and starving the encode block | Cap game FPS first, then revisit |
| Average render time near frame budget | Composite is at the edge — 16.67 ms at 60 fps | Reduce sources, filters, browser sources |
That last row deserves a note, because it is the most useful number in the dock and the least used. If Average time to render frame is approaching your per-frame budget, you have no margin left, and any small disturbance will push you over. At 60 fps the budget is 16.67 ms; a render time above roughly 10 ms means you are living dangerously even if nothing has failed yet.
After the stream: the log file
This is the step almost nobody takes and it is the most reliable of the two, because the log states the totals plainly instead of asking you to watch a counter in real time. Open Help → Log Files → View Current Log and search the bottom of the file. OBS writes each frame-loss category as a separate, distinctly worded line[4].
Video stopped, number of skipped frames due to encoding lag: 412/216000 (0.2%)
Output 'adv_stream': Number of lagged frames due to rendering lag/stalls: 88 (0.0%)
Output 'adv_stream': Number of dropped frames due to insufficient bandwidth/connection stalls: 0 (0.0%)The wording is your index. “skipped … due to encoding lag” is the encoder. “lagged … due to rendering lag/stalls” is the GPU compositor. “dropped … due to insufficient bandwidth/connection stalls” is the network, and if that line is the only non-zero one then this whole page is the wrong page: you have an upload problem, and our Twitch Inspector guide is where to go. Note that the skipped line carries no output name, consistent with it being a property of the shared pipeline rather than of one stream.
A stable stream still needs someone watching it
Fixing the encoder removes a reason for people to leave. It does not by itself bring them. Streamrise delivers real Twitch viewers paced across days, so the curve reads as organic growth rather than a spike.
- 2021 delivering Twitch viewers since
- 60-day drop refund
- No password required
# Fixes, in the order OBS itself recommends
The OBS knowledge base publishes an ordered list for encoding performance problems, and its ordering is deliberate: the early items are cheap and frequently decisive, the later ones cost you output quality[3]. Most guides invert this and lead with “lower your resolution”, which is the step of last resort.
- Run OBS as administrator (Windows). OBS notes that it “can ask Windows to reserve some GPU capacity for its use” and that “in many cases, GPU overload issues can be resolved simply by running OBS Studio as administrator”. Free, reversible, and it costs you nothing in quality, so try it first.
- Check what else is using the GPU. Browsers with hardware acceleration, a second capture tool, video calls and wallpaper engines all take a share.
- Cap the game's frame rate or enable V-Sync. OBS is unambiguous: “the best option is to limit the game's framerate or enable vertical sync; this will free up processing power for OBS Studio to composite.” An uncapped game will always take everything available. This is the highest-yield step on a hardware encoder.
- Reduce the game's graphical settings. Frees GPU headroom without touching your stream's output quality.
- Disable Game Capture Multi-Adapter Compatibility (Windows). OBS: “There aren't many situations where you actually want to have this option enabled … In pretty much all other cases, you should disable this option.” It carries a real cost when it is on unnecessarily. See our game capture troubleshooting guide, where the same toggle appears for a different symptom.
- Disable Windows gaming features. “Game Mode can negatively impact other processes like OBS Studio”, and Game DVR “uses additional system resources”.
- Reduce output settings. Only now. Lower the output resolution, or the frame rate. OBS suggests that “if 60 fps is not working for you, try dropping it to 30”. Halving the frame rate doubles the per-frame budget from 16.67 ms to 33.3 ms, which is a much larger change than it sounds.
- Build simpler scenes. Fewer sources, fewer filters, and in particular fewer browser sources, each of which runs a browser engine.
One thing worth saying plainly, because the warning's own wording pushes you toward it: “using a faster encoding preset” helps only in the software-encoding case. If you are on a hardware encoder, the preset dropdown is a different mechanism entirely and changing it is unlikely to address a GPU that is fully committed to rendering your game. The message is generic; your situation is not.
Finally, resist the urge to change several things at once. Each change alters the counter you are using to measure success, and the cumulative percentage does not reset until every output stops. Change one thing, restart all outputs so the baseline is clean, and watch the Stats dock for a few minutes. If you want to sanity-check that your bitrate is not a separate problem sitting underneath this one, our OBS bitrate calculator gives you a target for your resolution and upload.
# Bottom line
“Encoding overloaded” is a sensitive frame-deadline alarm wearing the costume of a resource monitor. It needs one bad second and a session that has already logged a trace of skipping, and it will keep firing on that basis long after the original cause is gone. Your CPU percentage is not the measurement it is making, and on a hardware encoder it is not even measuring the right chip.
So the sequence that works is: read the Stats dock to find out whether you are skipping or missing, look at per-core rather than aggregate CPU, cap your game's frame rate before you touch anything in OBS, and change one variable at a time with a clean baseline between attempts. Lowering your output resolution is the last step in OBS's own ordered list, not the first, and reaching for it early usually means giving up quality for a problem you had not yet identified.
# Frequently asked questions
Why does OBS say encoding overloaded when my CPU usage is low?
Because the warning does not read CPU usage. It fires when more than 10 frames are newly skipped within a single one-second check and the session's cumulative skipped share is at least 0.1%. A one-second stall can skip a dozen frames while barely moving a CPU average that is smoothed over the same second and divided across every core. On top of that, if you use NVENC, AMF or QuickSync the encode runs on the GPU, so processor load is not measuring the relevant component at all.
Is 0.1% skipped frames actually bad?
On its own, no. At 60 fps, 0.1% is roughly one frame every sixteen seconds, which viewers will not perceive. The threshold is deliberately sensitive so the warning appears early. What matters is the trend: a percentage that keeps climbing through the stream indicates a real and continuing bottleneck, whereas a figure that reached 0.1% once and then stayed flat is history, not a current fault.
Why does the warning appear out of nowhere in the middle of a good stream?
Because the percentage condition is cumulative and never recovers. Once your session total has passed 0.1%, that half of the test stays satisfied permanently. From then on any single second with more than ten skipped frames triggers the toast, however long ago the original trouble was. Stopping and restarting all outputs clears the baseline and tells you whether anything is actually wrong right now.
Does the warning mean my viewers saw a broken stream?
Not necessarily, and often not. Skipped frames are dropped before encoding, so the output video is briefly lower in effective frame rate rather than corrupted. At the threshold that triggers the warning the effect is usually imperceptible. A sustained and rising skipped count is a different matter and will read as stutter. Check the totals in your log after the stream rather than judging from the toast.
I only get this while recording, not streaming. Why?
Skipped frames are counted on the shared video pipeline, so recording and streaming draw on the same counter, but a local recording is typically configured at a much higher bitrate and often a higher resolution than a stream. That is more data to compress per frame, so the encoder deadline is tighter. If you record and stream simultaneously, both encodes compete, and the skipped-frame counter covers the whole period during which any encoder is active.
Will switching to NVENC fix encoding overloaded?
It depends on which component is short of headroom. If a single CPU thread is saturated while your GPU is calm, moving the encode to NVENC usually resolves it completely. If your GPU is already at 100% running an uncapped game, switching to NVENC moves the work onto the component that has no capacity left, and it can make things worse. Establish which case you are in from the Stats dock before you change encoder.
How do I clear the encoding overloaded warning?
The toast itself clears after four seconds. The underlying counter state clears when every output stops and one starts again, because the status bar captures its baseline at output activation and the pipeline counter resets when the first encoder attaches after all had stopped. Stopping and restarting is a measurement reset, not a fix — it gives you a clean reading so you can tell current problems from accumulated history.