Upscale an OBS recording — after you fix the capture settings

OBS composes your scene at a base canvas resolution and then writes the file at an output resolution, which by default equals the canvas. The moment you set the output lower than the canvas, OBS downscales in real time and the recording only ever contains the smaller frame. Everything a later upscale does to that file is enlarging a downscale, not reconstructing a lost original. If your delivery target is 1080p, record at 1080p; a 720p capture that will be delivered at 1080p has already thrown away more than half the pixels before anyone touches it.

The downscale filter matters too, and it is a genuinely different choice from the encoder. OBS offers filters that range from sharp to smooth, and the sharp ones cost a little more compute while holding edges together better. But all of them discard pixels — the question is only which pixels survive. Picking a good filter is a way of losing less, not a way of keeping everything, so it does not rescue the decision to record a smaller output than you intend to deliver.

The same ceiling applies when you capture a window or a display rather than a game's own output. A full-screen capture of a 1080p interface onto a 720p canvas is a 720p recording of that interface, however crisp the source was on the monitor. Record at the frame size you intend to publish, and treat any later enlargement as repair work rather than as part of the pipeline.

Two encoders sit behind most OBS recordings: a software encoder that spends CPU time packing each frame efficiently, and the hardware encoders built into GPUs and capture hardware that spend almost no CPU and lean on dedicated silicon. Software encoding at a slow setting generally produces a better picture at the same bitrate; hardware encoding generally keeps up with high frame rates and heavy scenes where software would drop frames. Neither is free: you trade CPU headroom against bits.

What actually decides how the recording looks is how many bits each frame gets. A fixed bitrate divided across sixty frames a second leaves half the bits per frame that thirty frames a second would get, which is why a recording can look acceptable in a still frame and fall apart during a fast pan. Dark areas lose their gradients first, particle effects and confetti turn into blocks, and motion smears because the encoder has no bits left to describe how the scene moved.

That is the failure an upscale is actually good at. Blocking and mosquito noise around hard edges are compression artefacts with a recognisable shape, and a model trained on video can soften them and rebuild plausible texture around them. What it cannot do is give back the motion detail the encoder dropped, so a pan that smears will still smear — it will simply be a smoother, larger smear. This is also why the encoder choice matters less than the bitrate you allowed it.

On the repair side, the pass has a real job: it makes a low-bitrate or downscaled recording look markedly less blocky, holds edges together after an enlargement, and gives the footage enough apparent resolution to sit in a larger frame without obvious stair-stepping. For an archive clip that is otherwise good — the moment is right, the framing is right, only the encode was stingy — that is often the difference between publishing it and leaving it on disk.

On the limit side, no model recovers information that was not written. Detail thrown away by a downscale is gone; motion smearing stays smeared; a dropped or torn frame stays broken. And screen recordings add a specific hazard: interface text is the hardest content there is for this class of model, because thin high-contrast strokes give it almost nothing to work with and it may predict a plausible letter that is not the one on screen. For a tutorial, a wrong glyph in a menu label is worse than a soft one.

Colour is its own trap. Most capture pipelines record chroma at reduced resolution, so saturated text on a contrasting background can show colour bleed that survives an upscale or even sharpens into something more visible. If the original has a washed-out or crushed look from a colour-range mismatch, an upscale will faithfully preserve that mistake at a higher resolution. Fix the recording when the problem is a capture misconfiguration; upscale when the problem is genuinely compression.

Do not send a two-hour session to an upscaler. Watch the recording once, note the timecodes of the moments that actually matter and actually look bad, and export each of them as a short slice at the recording's native frame size. A handful of fifteen-second slices from a long session is a small job that fixes the parts you will publish; the same session submitted whole is a large bill for footage nobody will watch twice.

Cut carefully, because a careless cut adds a generation of compression before the upscale even starts. Cutting on keyframes and copying the stream avoids re-encoding entirely, though your cut points will snap to whatever interval the recorder used. Cutting precisely at an arbitrary frame means re-encoding that slice once — worth it when the moment is short, and best done with a high-bitrate or intermediate codec so the upscale receives clean input rather than a second-hand encode.

Bringing the result back is a replacement, not a remix. Keep the original recording's audio: the upscale request carries video only, so the soundtrack stays in your editor and is re-attached to the enhanced slice. Match the slice's frame size and frame rate to the sequence so it drops in without a conform, and put a short overlap or crossfade at each boundary, because a model's reconstruction can shift the look slightly from one slice to the next and a hard cut makes that visible.

The most valuable advice on this page costs nothing: set the canvas and the output to the resolution you intend to publish, and stop recording a smaller frame than you deliver. If you have been recording at a reduced output for years because a tutorial or a preset told you to, that single change does more for sharpness than any post pass, and it is free for every future session.

Then spend the bitrate. A local recording is not limited by upload bandwidth the way a live stream is, so there is no reason to record a local file at a rate chosen to survive a stream. If your encoder offers a quality-target mode instead of a fixed bitrate, use it for local recording; if you prefer a fixed rate, budget it for the worst scene you record, not the average one. Test thirty seconds of fast motion and inspect it frame by frame before committing to a long session.

Finally, treat a hardware encoder as a convenience with a quality setting attached, not as a free upgrade. It will hold a high frame rate where software might drop frames, which is often the right trade, but pushing its quality setting up is what keeps it from producing the soft, blocky file you would then be tempted to pay to repair. The split is simple: configure the capture correctly for everything you make from now on, and use the upscale only for the archive you already have.

At the Standard model, 1080p bills 540 credits per minute of submitted footage, which is 32,400 credits an hour. Billing starts at a five-second minimum, so a very short clip is not free but is still cheap, and one source can run up to 10 minutes — beyond that the file is split rather than submitted as one job.

Convert that to money at the Creator yearly rate of $0.0093 per credit: a minute of 1080p Standard work is about $5.01, an hour about $300. Creator's 106,800 credits cover about 197 minutes of 1080p Standard footage, or about 53 minutes at Standard 4K if the delivery genuinely needs the larger frame.

The arithmetic that matters for a streamer or a tutorial channel is the ratio between session length and usable footage. A three-hour session where six minutes are worth publishing is a six-minute job, not a three-hour one, because the meter follows the seconds you submit. Slicing first is therefore not only a quality decision — it is the difference between a small top-up and a plan-sized bill.