OBS Bitrate Calculator — the number that decides whether your recording looks cheap or clean

You can fix almost every recording quality problem before you press Record, and almost every one of them comes down to a single number: how many megabits per second the encoder gets to spend. Too low and gradients turn into staircases, confetti smears into noise, and fast pans dissolve into blocks. Too high and you burn disk for quality you cannot see, then wonder why a two-hour session ate 80 GB. This calculator gives you the number for your exact resolution, frame rate, codec and content motion, shows the ±15% range where taste and disk budget live, and converts it into GB per hour so the disk math is never a surprise.

What the result actually means

The tool answers three questions at once. First: what to type into OBS at Settings → Output → Recording → Bitrate (if you are on CBR/VBR) or what CQP level lands near that bitrate. Second: how much disk that choice costs per hour, per session, per week — using the same arithmetic the vault uses, so the estimate here and the file on disk agree. Third: what happens if you move one notch up or down, because the right bitrate is always a trade against something.

The headline number is in kilobits per second. 6,000 kbps means 6 Mbps means 0.75 megabytes per second of video, before audio. The ±15% range is not a confidence interval — it is the band inside which most people cannot tell the difference on the content they actually record. Below the band you will see artifacts on motion; above it you are paying disk for pixels the encoder already described perfectly.

The three knobs that actually determine the answer

Every bitrate recommendation is a function of three things. Resolution and frame rate set the pixel throughput: how many pixels per second the encoder must describe. Content motion sets the complexity: how much those pixels change between frames. Codec efficiency sets the cost per unit of quality: how many bits the chosen encoder needs to describe one unit of that change.

Pixel throughput is the easy part. 1080p30 is 62.2 megapixels per second. 1080p60 doubles it to 124.4. 1440p60 is 221. 4K30 is 248.8. Naive scaling says bitrate should scale linearly with pixel count — it does not, and the reason is the second knob.

Motion complexity is where every generic bitrate table on the internet fails you. A talking head at 1080p60 needs less bitrate than a first-person shooter at 1080p30. The encoder spends bits on what changed since the last frame. A static background with one moving face changes almost nothing; a camera whipping through a forest changes almost everything. This calculator encodes that as a motion multiplier: slides and still imagery at 0.6×, a talking head at 0.7×, screen sharing at 0.8×, general video at 1.0×, and high-motion gaming at 1.4×. Those ratios come from testing the same scenes across bitrates until artifacts appeared — the numbers are the floor where the artifacts start, not the ceiling where quality saturates.

Codec efficiency is the third knob and the one that ages fastest. H.264 is the baseline everyone can play. HEVC describes the same quality in roughly 0.6× the bits on hardware encoders. AV1 gets to roughly 0.5× but the hardware encode story is young and the CPU encode story is slow. The multipliers here are deliberately conservative: real-world HEVC savings vary between 0.5× and 0.7× depending on the encoder implementation, and quoting the best case would make your files land above the estimate.

Why recording bitrate is a different problem from streaming bitrate

Most bitrate advice is written for streaming, and streaming has one constraint recording does not: the pipe. A stream must fit your upload bandwidth with room for the game, the browser, and the OS, so streamers learn to squeeze. Recording has no pipe. The disk writes at hundreds of megabytes per second; the question is never "can the disk keep up" but "how many gigabytes do I want this to cost."

That freedom changes the right strategy in two ways. First: you can afford CQP (constant quality) instead of CBR (constant bitrate). CQP tells the encoder "spend whatever you need to hit this quality level" — quiet scenes get 2 Mbps, explosions get 14, and the average lands near what this calculator predicts. The OBS default x264 CQP 20 and NVENC CQP 20 both produce files whose average bitrate sits close to the balanced numbers here. CBR caps the peaks, which is exactly where quality lives in high-motion content. Second: you can afford to record above the upload target and re-encode later. The master is the only copy that contains everything you shot; every derivative is a lossy reading of it. Record at the balanced or max number, keep the master, and derive the 4.5 Mbps upload copy from it — never the other way around.

The anchors: where the table numbers come from

The calculator keeps a small table of hand-verified anchors, and falls back to a formula for everything else. The anchors exist because formulas drift at the edges — someone has to actually look at the output.

• 720p30 talking head, H.264: 2,500 kbps (small), 3,500 (balanced), 5,000 (max). Below 2,500 the face starts to swim against the background on camera motion; 3,500 is where it stops mattering.
• 1080p30 normal video, H.264 balanced: 6,000 kbps. This is the most-quoted number in OBS circles and it survives testing — for mixed content at 30 FPS it is the knee of the curve.
• 1080p60 gaming, H.264: 12,000 (balanced), 18,000 (max). The jump from 30 to 60 FPS costs more than the pixel doubling predicts because high frame rates expose temporal artifacts — a smeared frame at 30 FPS hides in motion blur, the same smear at 60 FPS reads as a glitch.
• 1440p60 gaming balanced: 18,000 kbps. Not 12,000 × 2.25 (the pixel ratio); the encoder's spatial prediction improves faster than pixel count at this resolution.
• 4K30 normal video balanced: 25,000 kbps. 4K is where people most often starve the encoder, because 25 Mbps "sounds like a lot" and the disk math gets scary — see the worked example below for what that fear costs.

Everything off the table runs the model: base by resolution (3,000 / 6,000 / 16,000 / 25,000 for 720p / 1080p / 1440p / 4K), times the FPS multiplier (60 FPS = 1.5×), times the motion multiplier above, times the codec multiplier, times the quality target (small = 0.7×, balanced = 1.0×, max = 1.4×), rounded to the nearest 500 kbps. The rounding is deliberate: no encoder cares about 4,731 vs 4,500, and clean numbers survive being typed into forum answers.

Three worked examples — hypothetical, labeled, with the arithmetic shown

Note for obs-bitrate-calculator: The three scenarios below are hypothetical examples (illustrative, not sourced case studies) for this specific tool — plausible input combinations with the calculator's own arithmetic shown, not measured lab files.

Example 1 — the interview podcast, 1080p30, H.264. Two cameras, mostly static, occasional hand gestures. Inputs: 1080p, 30 FPS, H.264, talking-head motion, balanced quality. The table anchor returns 6,000 kbps for normal motion, and the model would say 6,000 × 0.7 = 4,200 for talking motion — use 4,200 to 6,000. At 4,200 kbps the disk cost is 4.2 × 0.45 = 1.89 GB per hour; a 90-minute episode is 2.84 GB. At 6,000 it is 4.05 GB. The visible difference between them on a static two-shot is approximately nothing — spend the 1.2 GB on the second audio track instead, which you will actually use in post.

Example 2 — the FPS game, 1440p60, H.264. Fast camera, particle effects, HUD with fine text. Inputs: 1440p, 60 FPS, H.264, gaming motion, balanced. The anchor says 18,000 kbps. Disk cost: 18 × 0.45 = 8.1 GB per hour. A three-hour session is 24.3 GB — this is the example that convinces people to check free space before the session rather than during it. Dropping to 1080p60 lands on the 12,000 kbps anchor and 5.4 GB per hour. Whether your audience can tell 1440p from 1080p on a phone-sized clip is the real question; if the footage is for vertical clips, record 1080p and bank the disk.

Example 3 — the archive recording, 4K30, HEVC. A lecture series that must stay sharp on a projector in five years. Inputs: 4K, 30 FPS, HEVC, normal motion, max quality. The model: 25,000 × 1.0 × 1.0 × 0.6 × 1.4 = 21,000 kbps. Disk cost at that rate is 9.45 GB per hour — but HEVC's real-world efficiency on archive content (slides, slow pans) usually lands below the model, so plan for 8 to 9 GB per hour and let the file surprise you downward. The same content in H.264 balanced would be 25,000 kbps and 11.25 GB per hour for visibly identical quality. For archive, the codec choice is worth more than any bitrate tweak.

Edge cases the formula handles badly, and what to do about them

Dual-canvas recording. WeaverClip records landscape and vertical simultaneously; two encoders means two bitrates. The honest math is additive — 6 Mbps + 6 Mbps is 12 Mbps and 5.4 GB per hour, not 2.7. If your machine struggles with two hardware encodes (older Intel iGPUs), drop each canvas one quality tier rather than dropping one canvas.

Six-track audio recording. Audio is quoted separately and it is not free: 160 kbps × 6 tracks is 0.96 Mbps, adding 0.43 GB per hour on top of the video number. Esports layouts that split Discord, game, and mic into separate tracks should budget for it.

4K on a weak GPU. The model will happily say 25,000 kbps for 4K balanced, but the encode load at 4K is the real constraint on a GTX 1650 or an M1. If OBS reports skipped frames, the fix is 1440p with a bitrate bump — a sharp 1440p beats a dropped-frame 4K every time.

High-refresh gaming at 120+ FPS source. Record at 60. The encoder's temporal prediction gains almost nothing above 60 for clip purposes, and 120 FPS recording doubles the disk bill for frames that will not survive the first re-encode.

Screen content with fine text. Code, spreadsheets, and terminal text break at bitrates that are fine for video. The screen multiplier (0.8×) assumes typical UI motion; if your content is scrolling code, treat it as normal motion (1.0×) or bump one quality tier. Text artifacts are the most-commented-on failure in screen recordings.

When the number looks wrong — troubleshooting

The file is 40% bigger than the estimate. You are on CQP or VBR, not CBR — good. The estimate is the average; CQP spends more on complex scenes. The ±15% band covers CBR discipline; VBR/CQP content variance adds another 10–20% on top. If the overshoot is consistent, lower the CQP number by 2 and stop comparing against a CBR estimate.

The file looks blocky at the recommended bitrate. Check what you recorded against what you thought you recorded. OBS silently drops to a lower resolution if the encoder cannot keep up (Settings → Video shows the output resolution), and a 1080p bitrate applied to a 1440p canvas is starvation. The stats bar (View → Docks → Stats) shows "skipped frames" — any non-zero number there means the encode is the bottleneck and the footage is already damaged before bitrate enters the conversation.

Gradients band but everything else looks fine. That is a bitrate floor problem in a specific scene class — smooth gradients are the hardest thing for a block transform to describe cheaply. Bump one quality tier for recordings that are mostly sky, stage lighting, or product renders; leave everything else alone.

I set 50,000 kbps and it does not look better than 25,000. Correct — you found the saturation ceiling for your content. Above the max-quality anchor, extra bits describe noise the sensor added. Keep the lower number and spend the disk on a second copy instead.

Decision guide — what to actually choose

Start from the output, not the input. If the footage is for 30–60 second vertical clips, record balanced at 1080p and let the clip pipeline handle reframing — the extra pixels of 4K die in the crop anyway. If the footage is a master you will re-edit for years, record max quality in HEVC if your hardware supports it, and accept the 0.6× disk cost as the price of the archive. If you genuinely do not know, balanced H.264 at the anchor for your resolution is the correct default: it is the number most people should have been recording at all along, and the failure mode is "used slightly more disk" rather than "lost the take."

One rule above all the others: never lower bitrate to save CPU. If the encoder is the bottleneck, lower resolution or frame rate — bitrate cuts make the footage worse without making the encode faster.

How this connects to WeaverClip — without bullshit

The calculator's GB-per-hour number is the same arithmetic the vault uses (0.45 GB per hour per Mbps, decimal gigabytes). That is on purpose: the estimate you see here is the number that decides which plan fits, so there is no second set of math behind the pricing page. Whatever bitrate you pick, the helper uploads one-minute segments while OBS keeps recording, verifies each segment byte-for-byte before deleting it locally, and keeps a gap-aware timeline of what made it. The bitrate choice is yours; the guarantee that the file arrived is the product.

FAQ — the questions that come back

CBR or CQP for recording? CQP. Constant quality spends bits where the scene needs them; constant bitrate caps the peaks that quality lives in. CBR exists for streaming pipes, and your disk is not a pipe.

Does 60 FPS really need 1.5× the bitrate of 30? For content people watch at speed, yes. The multiplier is the tested floor where 60 FPS stops showing temporal smearing that 30 FPS would have hidden. Slow content (lectures, podcasts) can use 1.2× and nobody notices.

HEVC or H.264 — will my editor choke? Modern Premiere, Resolve, and FCP all edit HEVC; the choke risk is real on machines from 2019 or earlier and in some proxy workflows. If edit performance matters more than disk, H.264 remains the safe default. Record HEVC for archive, derive H.264 for the edit.

What keyframe interval goes with these numbers? Two seconds, regardless of bitrate. Keyframe interval affects seek granularity and edit cut points, not the quality-per-bit of the surrounding frames.

Why does the calculator round to 500 kbps? Because 4,731 kbps is not a real setting — it is a false precision that does not survive a forum post or a preset file. Every encoder on earth treats ±250 kbps as noise.

My OBS preset says 10,000 for 1080p60. Who is right? Presets optimize for the worst case on the widest hardware. If your content is not the worst case, the preset is overspending. Run this tool for your motion class and compare — the difference is disk you get back every single session.

Appendix — the diminishing-returns curve, quantified

Quality per bit is not linear; it is a curve with a knee, and every anchor in this calculator sits at the knee for its content class. Below the knee, each 10% of bitrate buys visible quality. Above it, each 10% buys less than the previous one, and by 1.4× (the max-quality multiplier) you are in the region where a blind A/B is the only way to find the difference. That is why "small" is 0.7× and not 0.5×: below 0.7× the artifacts become the content's defining feature rather than its texture.

The practical consequence: if your disk budget forces a choice between one quality tier down and 30 FPS instead of 60, take the frame-rate cut for talking content and the quality cut for motion content. Temporal smoothness is what viewers forgive least in games; spatial detail is what they forgive least in faces. The calculator's three knobs are the vocabulary for making that trade deliberately instead of by accident.

If you want to check a real file against these numbers, the inspector on this site reads codec, resolution, and bitrate from any recording locally — no upload — and the storage calculator converts whatever it finds into per-week and per-month disk totals for your schedule.

Verifying that the recorded file matches the plan

Pick a number, record, and then confirm the file actually landed where you expected. The cheapest check is arithmetic, not inspection: file size in GB divided by duration in hours divided by 0.45 gives the effective total Mbps. A 90-minute file at 4,158 MB works out to 4,158 ÷ 1.5 ÷ 0.45 ≈ 6,160 kbps — right on the 6 Mbps video plus 160 kbps audio target. If the effective number sits 15–25% above your CBR setting, you recorded CQP or VBR and the average simply ran hot on complex scenes; that is normal, not a misconfiguration.

The second check reads the container directly:

`` ffprobe -v error -show_entries stream=codec_name,width,height,bit_rate -show_entries format=duration,bit_rate -of default=noprint_wrappers=1 recording.mkv ``

Compare format.bit_rate against the sum of your video and audio settings. MKV files written by OBS sometimes omit the container-level bitrate field — in that case the size-over-duration arithmetic above is the ground truth. If stream.bit_rate reads dramatically lower than your setting (say 2 Mbps against an 8 Mbps target), the encoder ran out of headroom: check the Stats dock for skipped frames, because a starved encoder usually means a struggling one, and the footage quality suffered during the encode rather than at playback.

This verification habit takes thirty seconds per session and catches the two mistakes that actually matter: recording at the wrong resolution, and recording at the wrong rate-control mode. Both are invisible until you look at a file that is mysteriously small.

Quick reference — common setups at a glance

The table below is what the calculator produces for the combinations people record most. Use it to sanity-check your own settings:

1. 720p30 talking head, H.264 balanced — 3,500 kbps, about 1.6 GB per hour
2. 1080p30 podcast or interview, H.264 balanced — 4,200 kbps, about 1.9 GB per hour
3. 1080p30 mixed content, H.264 balanced — 6,000 kbps, about 2.7 GB per hour
4. 1080p60 gaming, H.264 balanced — 12,000 kbps, about 5.4 GB per hour
5. 1080p60 gaming, H.264 max — 18,000 kbps, about 8.1 GB per hour
6. 1440p60 gaming, H.264 balanced — 18,000 kbps, about 8.1 GB per hour
7. 1440p60 gaming, HEVC balanced — 10,800 kbps, about 4.9 GB per hour
8. 4K30 lecture or mixed, H.264 balanced — 25,000 kbps, about 11.3 GB per hour
9. 4K30 lecture or mixed, HEVC max — 21,000 kbps, about 9.5 GB per hour
10. 4K60 gaming, H.264 max — 52,500 kbps, about 23.6 GB per hour

Two patterns jump out. Switching a gaming recording from 1080p to 1440p at the same 60 FPS costs 50% more disk for a modest sharpness gain that mostly disappears once the clip is reframed vertically. Switching the same recording from H.264 to HEVC saves about 40% at equal quality — for anyone recording several hours a week, that codec switch pays for itself within a month.

The GB-per-hour column is the one to plan around. Multiply by your weekly recording hours, and you have your monthly disk demand — which is exactly the input the storage calculator and the plan-fit math take. Bitrate is not an isolated number; it is the first link in a chain that ends with a full drive or a comfortable vault.