OBS Encoding Overloaded - What It Means and How to Fix It

"Encoding overloaded! Consider turning down video settings or using a faster encoding preset."

It is an unusually honest error message, and almost nobody reads it properly. It is not telling you that OBS is broken, that your PC is too weak, or that you need a better graphics card. It is telling you something precise:

Your encoder did not finish a frame before the next one arrived.

Once you understand the deadline it missed, every fix below stops being a superstition you copied off a forum and becomes arithmetic you can actually reason about.

The deadline your encoder missed

OBS hands your encoder a fresh frame at a fixed rate, and the encoder has until the next one arrives to compress it and get out of the way.

That is the entire budget. If your encoder needs 20 ms to compress a frame and you are running at 60 fps, it will never catch up. It falls further behind every single frame, OBS throws frames away to stop the queue exploding, and you get a stuttering file and a red warning.

Two consequences fall straight out of that table, and they are the two most useful facts in this article:

1. Dropping from 60 fps to 30 fps doubles your budget. It is the single most effective fix available, and for a screen recording it costs you nothing that matters. A cursor moving across a settings panel does not need 60 fps. Games do. Tutorials do not.
2. The encoder is the only thing under this deadline. Not your CPU in general, not your RAM. If the encoder gets its work done in time, OBS is happy even if the rest of your machine is busy.

You can watch the failures accumulate live: View, Docks, Stats, then look at Skipped frames due to encoding lag. That counter is this warning, in numeric form. Your target is zero.

Fix 1: Get off x264 and onto your GPU's encoder

By far the biggest lever. If you change one thing, change this.

x264 is a software encoder. It compresses video using your CPU's general-purpose cores, and it is very good at it, which is precisely the problem: it is thorough, and thorough is expensive. Meanwhile, your graphics card almost certainly contains a dedicated silicon block that does nothing but encode video, sitting completely idle.

That block does not compete with your game, your browser, or your IDE, because nothing else in your system uses it.

1. Settings, Output.
2. Set Output Mode to Advanced.
3. Open the Recording tab (or Streaming, or both).
4. Change Video Encoder from x264 to your hardware encoder:

5. Apply, then run a sixty-second test and check that Skipped Frames stays at zero.

"But isn't hardware encoding lower quality?" That reputation is a decade old. It came from the genuinely poor NVENC in the Kepler era. Modern NVENC (Turing, 2018, and later) is roughly comparable to x264 at the fast preset for the same bitrate, while using a small fraction of the CPU. For screen recording and streaming, the quality difference is not something you will notice. The stutter you are trying to fix definitely is.

Fix 2: If you are stuck on x264, move down the preset ladder

If your machine genuinely has no hardware encoder, x264's preset is your throttle. It controls how hard the encoder works to squeeze the file down.

Slower preset = better compression = more CPU. That is the whole trade.

Move one step at a time and retest. Most people overloading on x264 are fine at superfast, and the visual cost at a decent bitrate is small.

The rule people get wrong: a slower preset does not make your video look better at a fixed bitrate by magic, it makes it more efficient. If your encoder cannot hit the deadline, a slower preset gives you a worse result than a faster one, because dropped frames are far uglier than slightly softer compression.

Fix 3: Cut the pixel budget

Your encoder's workload is, to a first approximation, pixels per second. Here is what your settings actually ask of it:

Going from 1440p60 to 1080p30 cuts the encoder's work by 72 percent. There is no setting anywhere in OBS that buys you more headroom than that.

Settings, Video:

• Leave Base (Canvas) Resolution at your monitor's native resolution, so your layout stays correct.
• Set Output (Scaled) Resolution to 1920x1080.
• Set Common FPS Values to 30 for tutorials and walkthroughs. Keep 60 only for gameplay, where motion actually carries information.
• Set the Downscale Filter to Bicubic. Lanczos looks marginally sharper and costs noticeably more GPU. It is not worth it here.

If you are recording a 4K display, this is not optional. Encoding 4K60 in real time defeats most consumer hardware, and it produces a file that nobody's timeline wants to scrub through anyway.

Fix 4: For local recording, stop using CBR

This is where a lot of copied-from-a-stream-guide advice actively hurts you.

CBR (Constant Bitrate) holds your bitrate at a fixed number no matter what is on screen. That is exactly right for streaming, because streaming platforms want a predictable, steady data flow and hate sudden spikes.

For recording to your own hard drive, CBR is the wrong tool. A screen recording is mostly static: a settings panel that does not move needs almost no data, and then a scroll or a window transition suddenly needs a lot. CBR spends the same bitrate on both, wasting data on the still frames and starving the moving ones, which is exactly where blockiness appears.

Use quality-based rate control instead:

• NVENC: set Rate Control to CQP, and CQ Level to 20 (range roughly 18 to 23; lower is better quality and a bigger file).
• x264: set Rate Control to CRF, and CRF to 20 (same range applies).
• Apple VT: use CRF or the quality slider around 70 to 80 percent.

The encoder then spends bits where they are needed and skips the frames that have not changed. You get a smaller file, a sharper image, and less encoder pressure on the static screens that make up most of a tutorial.

Keep CBR for streaming. Use CQP or CRF for recording. They are not interchangeable.

Fix 5: Make sure something else is not already using the encoder

Occasionally the encoder is not overloaded by your settings but by a second tenant. Worth checking if the numbers do not add up:

• You are recording and streaming at the same time. That is two encoder sessions. In Settings, Output, Recording, set Encoder to (Use stream encoder) so both share one session, unless you specifically need a higher-quality local file.
• A browser is hardware-accelerating video in the background. A Chrome tab playing a video and a dozen Twitch panels are using the same silicon. Close them.
• A second OBS instance, or a stray one that never exited. Check Task Manager.
• Your GPU drivers are old. Encoder performance and stability genuinely improve between driver releases. Update from NVIDIA or AMD directly, not from Windows Update.

Verify it, do not assume it

Change one thing, then run a sixty-second test with something demanding on screen: scroll a long page fast, drag a window around. Stop, and check Stats.

Skipped frames due to encoding lag should read 0. If it does, you are done and you should not touch anything else. If it does not, go one more step down the preset ladder or one more step down the pixel budget.

The settings you should not have to pick

None of this is difficult, exactly. It is just knowledge you had to acquire in order to record your screen: what an encoder is, what a preset ladder does, why CBR is wrong for local recording, and how many pixels per second your particular GPU can chew through.

That is a genuine prerequisite for running a live broadcast. It is a strange prerequisite for recording a product demo.

Cubix Capture detects your hardware encoder and configures the frame budget for you, so there is no preset to ladder down and no overload warning to interpret. It also builds the parts of the video that would otherwise be an editing job: automatic zooms that follow your cursor to whatever you are clicking, and smoothing that turns jittery trackpad movement into a clean glide.

Keep reading: OBS high CPU usage · OBS lagging, diagnose it first · OBS best settings for screen recording · screen recording lag, every platform