How to Stream iRacing with OBS Without Lag — Single-PC Settings That Work

Streaming iRacing from a single PC is a resource war. The sim wants 100% of the GPU to render 60 cars at 120 Hz, the encoder needs its own slice of that same chip to push video out, and one wrong setting in OBS breaks both at once. I found that out the hard way on my own stream, and this is the exact debugging process — and the exact fix — that got it clean.

My rig is one PC: RTX 5060 Ti 8 GB, Ryzen 7 5700, 32 GB RAM, gigabit wired ethernet, 1440p 120 Hz G-SYNC Compatible monitor. No capture card, no second encoding machine. Everything you're about to read applies directly if you're in the same boat.

The symptom: a stream that lagged and clipped

Viewers were seeing stutters and dropped segments — the classic "your stream just froze for a second" comments in chat. The picture would hitch, catch back up, then do it again a few minutes later. No single moment was catastrophic, but it was constant enough to be distracting, and I couldn't tell from the preview window alone whether it was my GPU, my encoder settings, or my connection.

So I stopped guessing and went to the source of truth: the OBS log file.

How to read your OBS log like a mechanic

OBS writes a detailed log for every session to %APPDATA%\obs-studio\logs. Open the most recent one after a stream and search for three specific phrases — each one points at a different subsystem, and each one has a different fix. Guessing at settings without reading this first is how people "fix" the wrong thing.

In my log, all three were present in the same session: 17.1% of frames skipped due to encoding lag, 6.7% lagged due to rendering lag, and dynamic bitrate collapsing from 4500 down to 2500 kbps. That's not one problem — that's three separate causes stacked on top of each other, and each needed its own fix.

The settings that actually work on one PC

Here's the known-good config I landed on, running live on the RTX 5060 Ti alongside iRacing at 100% GPU load. These are the values in my OBS output settings right now.

Turning off Multipass and Look-ahead alone accounted for most of the encoding-lag fix. Both features exist to improve compression efficiency, and both do it by making the encoder do more work per frame — exactly the wrong trade when the encoder is already sharing a chip with a sim running at 100% load.

Why not AV1?

AV1 and HEVC are objectively better codecs than H.264 — better quality per bit, at a given preset. But that comparison assumes equal preset weight, and on a single shared GPU, preset weight is the variable that actually matters.

My original setup was AV1 at Preset P6 (Slower) with two-pass Multipass and Look-ahead both on — the "best quality" configuration by every slider in the menu. On paper that should look great. In practice, it was asking the same NVENC chip that's also feeding iRacing's own rendering to do the heaviest possible encode job, and it couldn't keep up. That's exactly where the 17.1% skipped-frame number came from.

H.264 at Preset P5 with Multipass and Look-ahead off is a lighter job for the encoder, full stop. It gave up some theoretical compression efficiency and got back a stream with effectively zero skipped frames. That's the trade that matters on one PC.

If you're running a dual-PC setup — one machine dedicated to the sim, a second dedicated to capture and encode — or you have a GPU purely for encoding duty, this calculus changes. AV1 or HEVC at a heavier preset becomes viable because nothing else is competing for that chip. But if you're streaming and racing off the same single GPU, match your preset to what the chip actually has spare, not to what looks best in a settings menu.

Cap your FPS — the fix nobody does

This was the fix for the second problem: the 6.7% "lagged frames due to rendering lag." That number isn't about the encoder at all — it's OBS's own compositor not getting enough GPU time to assemble frames, because iRacing was rendering as many frames as the GPU could physically produce, uncapped, all the time.

An uncapped frame rate doesn't make your own gameplay meaningfully smoother once you're well above your monitor's refresh rate — it just means the GPU never stops handing frames to the game, which starves everything else running on that GPU, including OBS's renderer.

The fix: cap iRacing's frame rate through the NVIDIA App's per-program settings, not in-game. My monitor is 120 Hz G-SYNC Compatible, and I capped it at 117 fps — refresh rate minus 3. That headroom keeps every frame inside the variable refresh rate window (so you're not bouncing in and out of VRR sync at the top edge) while handing back a meaningful slice of GPU time to everything else on the system. That freed-up headroom is what fixed the rendering-lag number.

Display Capture vs Game Capture

This one's a genuine trade-off, not a clean answer. Game Capture is lighter on system resources than Display Capture — it hooks the specific game window and generally costs OBS less to composite. If you're chasing every last bit of headroom, Game Capture is the cheaper option.

I kept Display Capture anyway, deliberately. I run a telemetry overlay app (RaceLab-style) that renders as its own separate window layered on top of iRacing — lap times, delta, inputs. Game Capture hooks the game process specifically and will drop any other window sitting on top of it, including that overlay. Display Capture grabs the whole screen, so the overlay stays on stream.

If you don't run a separate overlay window, switch to Game Capture — it's the lighter option and there's no reason to pay the extra cost. If your layout depends on windows outside the game itself, Display Capture is what puts them on stream, and it's worth the small extra resource cost once the encoder and FPS cap fixes above are already in place.

FAQ