HandBrake does not upscale video — it encodes what you already have

HandBrake decodes a file, runs the frames through filters, and re-encodes them with the codec and settings you choose. That is a real and useful job, and it is the only job this page claims for the application. It is not an enhancer. Hand it a soft 720p clip, set the output width to something larger, and it will write that many pixels across — but every one of those pixels is an interpolation of pixels the decoder found, not a recovered piece of the scene.

The productive order is therefore: reconstruct first, inspect, encode last. Run the segment through a model that predicts detail, look at the result at full size, then use HandBrake to produce the file your platform actually accepts. HandBrake's strengths sit entirely in that final step — codec choice, quality-based rate control, container and audio handling, and the ability to target a size limit without guesswork. A delivery tool used as a delivery tool is worth a lot; the same tool used as an upscaler is worth very little.

The misconception is easy to understand, because the dimensions panel looks like an upscale control. It is a scaling control. It answers the question 'how many pixels should the output frame have', not the question 'where does the missing detail come from'. Those are different questions, and HandBrake only answers the first one.

When you enlarge the output frame, the decoded picture has to be stretched to fill it, and that stretch is a scaling filter. The filter choices a transcoder offers — nearest neighbour, bilinear, bicubic, Lanczos and similar names — are all resamplers. They differ in how they weigh neighbouring pixels and how much ringing or softness they introduce, but they share one property: the output is a function of the input pixels alone. Nothing is inferred about what the scene contained.

This is why a HandBrake 'upscale' looks like a larger copy of the same soft image. Interpolation cannot add information, because the amount of detail was fixed at decode time. What the filter can change is apparent sharpness, and that is paid for elsewhere: over-sharpened edges grow halos, diagonals turn into stair steps, and compression blocks in the source are magnified into visible tiles along with everything else.

A reconstruction model starts from a different premise. Instead of averaging neighbours, it predicts what plausible structure would sit there given what it has learned about how images are built. That is still prediction, and it can be confidently wrong — skin can turn waxy, lettering can change shape, fine patterns can shimmer — which is why a test segment and a full-size comparison matter more than any model name. What a model will not do is recover the actual detail the camera missed; that information was never recorded, and no amount of processing invents it.

A well-configured transcode preserves the things you asked it to preserve: frame size, frame rate, duration, audio, the container's metadata and roughly the colour information. What it does not preserve is detail the encoder decides it cannot afford. Lossy compression spends a budget of bits, and every block of the picture has to fit inside it, so the encoder discards the parts of the image a viewer is least likely to notice at the chosen quality — fine texture, subtle gradients, the precise shape of an edge.

Decoding that file and encoding it again does not restore what the first pass dropped. The second encoder starts from an image that is already missing detail, and it has to make new decisions about what else to drop; it also spends bits describing the first pass's artefacts, which are now part of the picture. The result is generational loss: subtle at one step, obvious after several, and always in the same direction — softer, blockier, more banded.

The practical rule is to keep an intermediate master between steps. If a file has to pass through more than one processing stage, give the middle stage a format that is designed for it — a mezzanine or intermediate codec, or a high-bitrate setting that is close to transparent — and save the compact delivery encode for the very end, once you know the picture is final. That single habit removes most of the quality complaints that people blame on the upscaler.

Codec choice is a compatibility decision before it is a quality decision. The older, widely supported codec plays everywhere and is the safe choice for a file that has to open on someone else's device. Newer, more efficient codecs buy smaller files at comparable quality, at the cost of slower encodes and weaker support on older hardware and browsers. Hardware-accelerated encoders are much faster but generally give up some efficiency and fine-detail handling compared with a careful software encode, which matters more on already-processed footage than on a clean camera original.

For an upscaled file, quality-based rate control is usually the better fit. It lets the encoder vary the bitrate with the difficulty of each scene instead of forcing every second into the same budget. A fixed bitrate chosen for the original resolution is the wrong budget for a larger frame: more pixels need more bits to hold the same quality, so a cap that looked generous before the upscale can now starve the picture and throw away exactly the detail the pass was paid for. If a platform imposes a hard bitrate limit, verify the result at full size before you publish, because the encoder will meet the limit whether or not the picture survives it.

Settings do not transfer automatically between a camera original and an upscaled version of it. The upscale changes the texture the encoder is looking at — some areas become smoother, some become busier with predicted detail — so a setting that was tuned on the original should be re-checked on the processed file. Encode a short segment at two or three candidate settings, compare them at one hundred percent on a good display, and only then commit the whole file. A test encode costs a few minutes; a wrong delivery encode costs the upscale.

The chain that works is short: reconstruct the segment, inspect it at full size, encode it once for delivery, publish. Each arrow is a decision point, and each one is cheap to repeat before the next begins. Inspecting before encoding matters because the encode is where detail goes to die: once you have compressed the upscaled file, you are judging the compressed version, not the upscale, and a disappointing result no longer tells you which step was at fault.

The chain that fails is encode, upscale, encode again. It fails for three compounding reasons. The model receives a source that has already been re-compressed, so it is predicting detail onto blocks and banding that were not in the original scene, and it may even sharpen those artefacts. The intermediate encode has already discarded detail that the model could have used. And the final encode compresses a picture that has now lost detail twice, so the delivered file can look worse than the original — flat, soft and covered in blocks — even though the upscale in the middle was good.

If you already made a delivery encode and now want to upscale, go back to the highest-quality master you still have rather than using the delivery file. If the delivery file is all that survives, accept that the ceiling is lower and say so before anyone spends credits. The same warning applies in reverse: do not upscale a finished delivery file 'just to sharpen it' and then encode it again for the same platform. That is two extra generations for a marginal, often negative, return.

The hosted pass bills the duration you submit, not the duration of the finished programme. At the Standard model, 1080p bills 540 credits per minute of source footage, which is 32,400 credits an hour, and a single source can run up to 10 minutes. Those are the reference figures for budgeting, because a delivery-minded job is usually a 1080p job: footage that has to survive a clean 1080p upload, or a shot that has to sit inside a 4K delivery without falling apart.

Convert 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 roughly 197 minutes of 1080p Standard footage, or about 53 minutes if the deliverable genuinely needs a 4K frame. Choosing 4K when the platform will not show 4K is paying for pixels nobody sees.

The only real saving is trimming before upload. Credits follow the seconds you hand over, so cutting the file down to the segment that actually needs the pass reduces the bill proportionally. HandBrake can export just a range, but that export is itself an encode — a generation the model will then have to work from. If a lossless cut is available to you, prefer it, because it removes duration without spending a generation. Either way, do the trim before the upscale, and keep the full-resolution original untouched.