OBS Recording Settings Generator — settings that fit your machine, not a forum's machine

"Best OBS settings" is an unanswerable question as usually asked, because the answer depends on three things the question never states: what your hardware can encode without choking, what your content does between frames, and what you need the recording to survive. A setting that is perfect on a gaming PC with an RTX 4080 is a dropped-frame disaster on a 2019 MacBook Air, and a preset tuned for a talking head wastes half its bits on a rocket-league replay. This generator asks the questions that matter — OS, GPU, CPU, resolution, frame rate, what you record, how much you care about file size — and answers with a complete preset: encoder, rate control, bitrate, keyframe interval, audio, and container, each with the one-sentence reason it was chosen.

What the preset actually contains, and why each field is there

Encoder. The single most consequential choice, because it decides which piece of silicon describes your frames. The generator picks from what your machine actually has: Apple VideoToolbox on macOS, NVENC on NVIDIA GPUs, and software x264 when no hardware encoder is available. Getting this wrong is the most common cause of dropped frames — the CPU doing a job the GPU could have done for free, or vice versa.

Rate control. How the encoder spends its budget. For recording the generator defaults to CQP — constant quality — where a level number (18–23 in the presets here) tells the encoder "hold this quality, spend whatever bits it takes." Streaming guides say CBR; that advice is about network pipes, and recording has none. CQP's files vary in size but not in quality, which is exactly what an archive wants.

Bitrate. The expected average under CQP, or the cap under VBR — shown so the disk math is knowable before you press Record. The generator sizes it from content type and frame rate: 6 Mbps for talk-style content, 8 Mbps for 30 FPS gaming, 12 Mbps for 60 FPS gaming, scaled down 30% for small-file mode and up 40% for max quality.

Keyframe interval. Two seconds, always. Keyframes are the seek points for everything downstream — players, editors, and clip pipelines cut on them. Two seconds is the convention OBS, YouTube, and most NLEs agree on; longer intervals save a few percent of bits and cost you edit precision forever.

Audio. 160 kbps AAC at 48 kHz per track. 48 kHz matters more than the bitrate: mixing 44.1 kHz sources into a 48 kHz project is a resampling artifact that reads as drift, and it is cheaper to prevent than to diagnose later.

Container. MKV on every platform, with fragmented MP4 as the alternative on macOS. This is the crash-safety decision, and the generator refuses to recommend plain MP4 for recording: MP4 writes its index once, at stop; MKV writes it continuously. If power dies mid-session, an MP4 is a forensic problem and an MKV is a one-line remux. The compatibility MP4 was chosen for is one ffmpeg command away afterward — record MKV, remux when the session is safely closed.

The encoder decision, in depth

This is where most settings guides stop at "use hardware encoding" and leave. The generator's actual logic, made explicit:

Apple Silicon (M-series) → VideoToolbox. The media engine on M1 and later encodes H.264 and HEVC without touching the performance cores, which is what keeps a video call, a browser, and OBS alive on the same machine simultaneously. On Intel Macs VideoToolbox exists but shares the CPU's thermal budget — the generator still prefers it there, but the small-file quality tier is the honest choice on those machines.

NVIDIA GPU → NVENC. A dedicated encode block on the card. The reason gamers use it is not that it is better than x264 at equal settings (it is marginally worse) but that it costs zero game performance — the encode happens on silicon the game never touches. NVENC's CQP holds quality unusually well across scene changes, which is why the preset pairs it with CQP 20 balanced or CQP 18 max rather than a bitrate cap.

AMD GPU → AMF, with a caveat. AMF works, and the generator will route there on AMD-only machines, but its quality-per-bit trails NVENC at the same settings on most driver generations. If you are on AMD and quality matters, bumping one quality tier costs less disk than you think and buys back the gap.

Intel iGPU → Quick Sync. Fine for talking heads and screen content; the encoder's motion handling shows on fast games. The generator treats it as "hardware encode, conservative motion expectations."

No GPU → x264. Software encoding, and the only honest advice is about the preset ladder: medium is the quality/speed reference point, fast and veryfast trade quality for CPU headroom. The generator's why-string says exactly this — on a mid or older CPU, start at veryfast and only move down the ladder if the stats bar shows headroom. A recording with dropped frames is worse than a recording at one preset faster.

Three generated presets — hypothetical machines, real logic

Note for obs-recording-settings-generator: The three machines below are hypothetical examples (illustrative, not sourced case studies) for this specific tool — plausible hardware profiles run through the generator's own decision logic, not benchmarked rigs.

Machine 1 — M2 MacBook Air, weekly podcast. macOS, Apple Silicon, 1080p30, podcast type, balanced quality. The generator returns: Apple VT H264 Hardware, CQP 20 balanced, 6,000 kbps video plus 160 kbps audio, 2-second keyframes, MKV or fragmented MP4. Estimated size 2.8 GB per hour. The why: VideoToolbox leaves the CPU for the call software, and MKV means a dead battery mid-episode loses a minute, not the interview. A fanless Air throttles under sustained x264 — this is the machine where the encoder choice matters most.

Machine 2 — RTX 3060 gaming tower, 1440p60 streams. Windows, NVIDIA, 1440p60, gaming type, max quality. The generator returns: NVENC H.264, CQP 18 with a VBR cap at 12 Mbps for upload-derived copies, 16,800 kbps expected average (12,000 gaming base × 1.4 max-quality), 48 kHz audio, MKV container. Estimated size 7.9 GB per hour — the number that should decide whether the session's second track and the replay buffer fit on the drive before the raid starts. NVENC keeps game FPS untouched because the encode never shares silicon with the render.

Machine 3 — 2018 Linux box, no discrete GPU, screen recordings for a course. Linux, no GPU, older CPU, 1080p30, screen type, small-file quality. The generator returns: x264 at veryfast, CQP 23 with a 6 Mbps VBR fallback, 4,200 kbps expected (6,000 × 0.7), MKV. Estimated size 2.0 GB per hour. Screen content is the kindest possible workload for a weak machine — almost nothing changes between frames — which is why the small-file tier is the honest recommendation here instead of balanced. The course will look identical at half the disk cost.

Where generated presets meet reality — things to check after the first test recording

Generate, then verify with a two-minute test before any real session:

1. Stats dock open (View → Docks → Stats). During the test, "skipped frames" must stay at zero and "missed frames" near zero. Any skipped frames means the encoder is behind — drop one preset step (x264) or one quality tier (hardware) and re-test.
2. File size sanity. Two minutes at the estimated rate should land within about 20% of the per-minute number. CQP files run hot on complex scenes; a test of a static desktop underestimates a test of gameplay. Test what you will actually record.
3. Audio path. Confirm each track appears in the recording (right-click a source → Advanced Audio Properties shows track assignment). The generator's 160 kbps × 48 kHz assumes tracks are routed; the settings cannot fix routing.
4. Container honesty. After stopping the test, open the file. If the duration reads correctly and seeking works, the container closed cleanly — the crash-safety promise of MKV is that even an unclean close leaves it playable.

Edge cases

Dual-machine recording (game PC plus streaming/encoding PC with a capture card): the capture card is a source, not an encoder relief — the encoding machine's limits still govern. Size the preset for the encoding machine, and treat the card's output resolution as your canvas ceiling.

Recording a console through a capture card at 4K: most cards pass 4K through but record 1080p, or record 4K with a latency penalty. Set the canvas to what the card actually records; a 4K canvas fed 1080p signal is an upscale that costs disk for invented pixels.

Laptop thermal limits: sustained encode on a thin laptop throttles regardless of encoder choice. The honest fix is the quality tier (small), which lowers the CQP level's bit demand and with it the thermal load — or recording plugged in with the lid open, which is a workflow answer, not a settings one.

HDR content: recording an HDR source into an SDR pipeline washes out; into an HDR pipeline it demands HEVC or AV1 to keep file sizes sane. The generator's presets are SDR by default because that is what the clip platforms deliver — if your workflow is HDR-first, treat every disk estimate here as a lower bound and the container advice as unchanged.

When the same machine records and streams: the stream encoder and the record encoder can differ in OBS. Use the hardware encoder for the stream (the pipe needs CBR anyway) and the generator's preset for the recording — two encoders on one GPU is fine on NVIDIA, marginal on AMD, and not possible on one x264 budget.

Troubleshooting the preset after the fact

Dropped frames at the recommended settings. The encoder, not the bitrate, is behind. For x264: move medium → fast → veryfast. For hardware encoders: raise the CQP number by 2 (fewer bits demanded per frame). Do not lower the bitrate — CQP does not use it as a cap, and the real problem is encode speed.

Files are twice the estimate. Either the content was far more complex than the type selected (a "podcast" preset applied to a music show with moving visuals) or the quality tier was maxed. Check which by looking at the actual average bitrate with ffprobe; if it is near the estimate's number, the estimate's content class was wrong, not the settings.

The recording plays but desyncs after ten minutes. Not a settings-generator problem — that is a clock drift or resampling issue, and the audio sync calculator on this site exists for exactly it. The one preventive setting: 48 kHz everywhere, which this preset already enforces.

OBS resets to defaults after an update. Presets live in profiles and scene collections; the generator's output is worth saving as a profile (Profile → Export) so an OBS update cannot cost you the configuration. Two seconds of export prevents an hour of re-derivation.

The first minute of every recording looks worse. Keyframe placement: the file opens on whatever frame recording started, and quality ramps to the CQP target over the first GOP. If the opening matters, start recording three seconds before the content does.

Decision guide — when to regenerate

Regenerate the preset when any of the generator's inputs genuinely changed: a new machine, a new GPU, a new content type, or a move between balanced and small-file priorities. Do not regenerate for a one-off session — the preset is a standing configuration, and changing it per-session makes your archive incomparable (files from different settings do not cut together cleanly, and bitrate differences read as quality flicker in a compiled video).

If you are choosing between this generator and a streaming guide's numbers: the guide optimizes for your upload pipe, this optimizes for your disk and your content. They agree only when your upload is unlimited and your content is average, which describes neither recording nor most creators.

How this connects to WeaverClip — without bullshit

The preset's container choice and the product's upload model are the same philosophy: assume the crash, design the recovery. MKV keeps the file alive when the session dies; the helper keeps it alive when the machine dies — one-minute segments go to the vault as they are written, each verified byte-for-byte before the local copy is released. Generate the preset, record through that path, and the settings page becomes what it should be: something you configure once and stop thinking about.

FAQ

Why does the generator say CQP when every YouTube video says CBR? Those videos are about streaming. CBR exists to fit a network pipe; recording has no pipe, so capping bits only caps quality on the scenes that need bits most. CQP holds quality and lets size vary — for an archive, that is the correct trade.

Can I use these settings for streaming too? The encoder and container logic transfers; the rate control does not. Streams need CBR at or under your upload limit minus overhead. Use the generator's encoder pick, then set a streaming bitrate separately.

H.264 or HEVC for the recording? The generator defaults to H.264 for edit compatibility. If your machine encodes HEVC in hardware and your editor is modern, HEVC at CQP 22–23 matches H.264 CQP 20 at roughly 60% of the file size — the right call for long-form archive recording.

Why 2-second keyframes instead of OBS's 0 (auto)? Zero means let the encoder choose, which usually lands around ten seconds. Ten-second keyframes make clip cuts imprecise and seeks sloppy. Two seconds is the standard the platforms and editors assume.

What changes if I add a second camera? Resolution and frame rate do not; content type might — a multi-camera podcast is still talking-head motion unless the cameras move. The bitrate holds because the background is shared; two faces on one background is not twice the complexity of one.

Does the generator know about AV1? The bitrate calculator does, for machines with AV1 encode hardware (RTX 40-series, RX 7000, M3 and later). The settings generator stays on H.264/HEVC because AV1's edit-toolchain support is still patchy in 2026 — record AV1 only if your entire downstream path is confirmed.

Appendix — the preset, as a copyable block

What the generator's output looks like for Machine 1 above, in the shape OBS actually stores it — this is the artifact to screenshot, export, or paste into a team wiki:

`` [Output → Recording] Format: MKV Encoder: Apple VT H264 Hardware Rate Control: CQP 20 Keyframe Interval: 2 s [Audio] Tracks: 1–2 at 160 kbps, 48 kHz [Video] Canvas: 1920×1080 Output: 1920×1080 @ 30 FPS [Expected size] ~2.8 GB/hour (6.0 Mbps video + 0.16 Mbps audio) ``

Every field traces to one of the generator's inputs, and every number traces to the arithmetic under it. That traceability is the difference between a preset you trust and a preset you copied from someone with a different machine, a different show, and a different definition of "looks fine."

Where each setting lives in OBS — applying the preset without hunting

OBS scatters these controls across three panels, which is half the reason people end up with mismatched settings. Here is exactly where each generated value goes.

• Encoder and rate control live under Settings → Output, after switching Output Mode from Simple to Advanced. The Recording tab, not the Streaming tab — they are configured independently, and the streaming tab's CBR habit is the one that leaks into recording setups by accident.
• Container format is in the same Recording tab, labeled "Recording Format." MKV is the default for a reason; the warning OBS prints about MP4 being unrecoverable is literal, not cautionary boilerplate.
• Audio bitrate and sample rate are split across two places: Settings → Audio sets the sample rate (make every device 48 kHz), while Settings → Output → Audio sets per-track bitrate. Track assignment per source is under the gear icon in the Audio Mixer → Advanced Audio Properties.
• Keyframe interval sits inside the encoder's own settings block, labeled Keyframe Interval (seconds, 0 = auto). Set it to 2.
• Canvas and output resolution are under Settings → Video. Keep Base (Canvas) and Output (Scaled) identical unless you deliberately want a downscale; scaling in OBS costs GPU cycles and adds softness that no bitrate can recover.

After changing anything, the Apply button does not restart encoders mid-recording, but it does not validate combinations either — the two-minute test recording described above is the only real check.

Operating system gotchas that no preset can fix

macOS. Screen capture requires Screen Recording permission, and microphone capture requires Microphone permission — both under System Settings → Privacy & Security. If OBS was installed before the permissions were granted, it may hold stale denials; toggle the permission off and on. macOS also counts iCloud "purgeable" space as free in Finder, so a drive that looks roomy can refuse a long write; point recordings at a folder on the internal APFS volume that is not synced, and keep at least 10–15% of the disk genuinely empty.

Windows. Two things bite recordists: Game Mode and hardware-accelerated GPU scheduling can, on some driver generations, starve NVENC when the game is fullscreen exclusive. If the stats dock shows encoder overload only during gameplay, run the game borderless-windowed. Also confirm OBS runs as administrator when capturing certain anti-cheat-protected games, or the capture source will show black.

Linux. VAAPI and PipeWire capture paths vary by distribution; on Wayland, window capture needs the PipeWire portal, and on some compositors it silently produces black frames. A two-minute test recording catches this before the three-hour session does. Filesystem choice matters too — record onto ext4 or XFS with real free space, not a mounted network share that can stall mid-write and truncate the tail of the file.

How the five content types change the preset

The generator's content-type input is not cosmetic; it moves both bitrate and the reasoning behind it.

• Podcast/Talk: mostly static framing, so the encoder idles between speech. The budget goes to keeping skin tones and fine hair detail clean at 1080p30; 60 FPS is wasted here.
• Gaming: the hardest workload. Fast camera motion defeats spatial prediction, so the base jumps to 8,000 kbps at 30 FPS and 12,000 at 60 FPS before any quality multiplier. Particle effects and HUD text are the first things to block when starved.
• Screen/Code: low motion but brutally fine detail. Bitrate can drop, but not too far — thin font strokes degrade visibly before the overall image seems to. The 0.8 motion multiplier reflects that.
• Course: slides plus a picture-in-picture face. Behavior resembles screen content with occasional full-frame transitions; the slide-like motion profile applies.
• Interview: two or more speakers, usually remote-composited. Treat like podcast, but if screen share happens inside the call, expect the encoder to spike during those segments — one more reason CQP beats a hard cap here.

Decision guide — which quality tier, honestly

Small is right when the recording is disposable input: a scratch take you will re-record, a meeting where only the audio matters, or a disk that is nearly full and you must capture anyway. Expect visible softness in motion.

Balanced is the default for a reason: it sits at the knee of the quality curve for each content class, where the next increment of bits buys diminishing visible returns. Most archives should live here.

Max earns its 1.4× disk cost when the footage is the master for paid products, heavy post-production, or archival where re-shooting is impossible — lectures sold as courses, wedding-adjacent work, one-shot live events. If you would be upset to lose the take, record max.

Whichever tier you pick, keep it consistent across a series. Mixing tiers between episodes makes color and noise grading inconsistent and betrays itself the moment two sessions cut together.