WARNING

Resolution Mismatch: Base vs. Output Scaling

A stream can look noticeably soft, blurry, or oddly cropped compared to what’s actually happening on screen, even when every other setting looks reasonable — and the cause is often a quiet disagreement between two separate resolution values that most people assume are the same thing, but aren’t.

Two different resolutions, doing two different jobs

Streaming and recording software typically distinguishes between what it captures from a source and what it ultimately outputs to viewers. The first — often called the base or canvas resolution — describes the actual detail being captured from whatever is on screen. The second — the output or scaled resolution — describes what’s actually sent out or saved, after the software has resized the captured image to fit. These don’t have to match, and there’s a reasonable purpose behind letting them differ: capturing at a higher detail level than what’s ultimately sent allows the software to shrink the image down cleanly, which tends to look sharper than capturing at a lower level to begin with.

The trouble starts when this relationship is set up backwards, or when the two values are chosen without any real reasoning behind either one — for instance, capturing at a lower level of detail than the output claims to be, which forces the software to stretch a smaller image up rather than shrink a larger one down. Shrinking a detailed image down preserves clarity reasonably well. Stretching a smaller image up doesn’t add detail that was never captured in the first place — it just makes the existing, limited detail larger and more visibly soft.

Why this produces a specific, recognizable kind of bad image

Unlike a bitrate problem, which shows up as stuttering or blockiness during motion, a resolution mismatch produces a constant softness or blur that’s present even when nothing is moving at all — because the flaw isn’t in how much data is being sent per second, it’s in the fundamental amount of visual detail that was ever captured to begin with. No amount of additional bitrate can fix this, because there’s nothing missing from the data pipeline — the image genuinely doesn’t contain more detail than what was captured, and increasing the data rate just sends the same soft image more faithfully.

This is a frequent source of confusion precisely because the fix people instinctively reach for — raising the bitrate, assuming the picture will get “clearer” — doesn’t address the actual cause and leaves the underlying softness untouched.

The principle behind fixing it

The underlying principle is straightforward once the two values are understood as genuinely separate: the base, captured resolution should be at least as detailed as the eventual output, ideally matching the actual source it’s capturing from, so that any resizing that happens afterward is a reduction rather than an artificial enlargement. A mismatch in the correct direction — capturing more detail than ultimately sent — costs very little and produces a cleaner result. A mismatch in the wrong direction produces a soft image no later setting can recover.

Because these two values live in different parts of a typical settings interface and are easy to configure independently without ever comparing them directly to each other, the more reliable check isn’t glancing at either number alone, but verifying the actual relationship between what’s being captured and what’s being sent — since it’s specifically that relationship, not either number in isolation, that determines whether the final image looks sharp or soft.

← Back to knowledge base