Resize a video

How it works

A frame of 1080p video is 1920 × 1080 samples, or 2,073,600 of them. The rung below it, 720p, is 1280 × 720, or 921,600. Stepping down once deletes 55.6 per cent of the picture before the encoder has spent a single bit describing what remains. No quality setting reaches that saving, because a quality setting still has to pay for all 2,073,600 positions and can only lower what it pays each one.

The public numbers agree. YouTube's recommended upload bitrates for SDR at standard frame rates are 8 Mbps at 1080p, 5 Mbps at 720p and 2.5 Mbps at 480p. Between the first two the pixel count falls 55.6 per cent while the recommended spend falls 37.5 per cent, so the smaller frame is handed more bits per pixel rather than fewer. Shrinking the frame buys a smaller file and a cleaner one together. Lowering the bitrate at a fixed size buys the first alone, and pays for it in blocking on anything that moves.

What each rung is for

1080p is the delivery size for something watched on a laptop or a television, and it is where most phones and cameras already record. 720p suits a clip that will be watched inside a feed, a chat window or a mail client, where the player is a few hundred pixels across and the surplus is discarded at the moment of display. 480p is for a file with a hard ceiling over it: an attachment limit, an upload cap, a form that refuses anything above a stated size.

2160p and 1440p are acquisition sizes. They earn their bytes while footage is still going to be cropped, stabilised or re-framed, since each of those operations eats resolution that cannot be got back. Sending one to a feed spends your upload rather than the platform's: every large service re-encodes what it receives into renditions of its own, so the file anyone plays was made by their encoder, and the extra pixels crossed the network to be discarded by a machine in a data centre.

A phone settles the same argument physically. Apple's published specification for the iPhone 15 display is 2,556 × 1,179 pixels at 460 ppi, so a 3,840-wide frame shown full screen there loses a third of its columns to the scaler before it reaches the glass. Acuity runs out before the panel does. One arcminute of visual angle, the 20/20 line on a Snellen chart, covers 0.12 mm at a 40 cm viewing distance, which is about 218 pixels per inch — less than half of what that panel already has.

Enlarging, and where the widths come from

A preset above the source is refused as an enlargement. A resampler asked for more columns than it holds interpolates between the pixels it was given, so the additions carry no detail anybody recorded, and the encoder is then obliged to describe every one of them. The result is bigger than the source, softer than the source, and slower to produce. Picking such a preset here reduces it to the source width instead, and the result line reports that the width was kept and why.

The widths come off the grid H.264 codes on. The standard divides a picture into 16 × 16 macroblocks (ISO/IEC 14496-10), and a width that misses a multiple of 16 is padded up to the next one, with the surplus columns cropped back off by the frame_crop offsets in the sequence parameter set. Those columns are encoded before they are cropped. Every long side offered here — 3840, 2560, 1920, 1280, 848, 640 — divides by 16, so 480p is offered at 848 rather than the 854 that circulates.

Short sides are less tidy and always have been. 1,080 lines is 67.5 macroblocks, so an H.264 encoder pads 1080p to 1088 and hides the last eight lines behind the crop offsets. Odd numbers get no such treatment: 4:2:0 chroma is subsampled by two in each direction, an odd side leaves a chroma sample with nothing to sit on, and the encoders here reject it. The shared video runtime rounds every side to an even number before a job starts.

What comes out

Changing the frame size touches every pixel, so the picture is decoded and encoded again and there is no copy path out of a resize. Output is MP4 for H.264, HEVC and AV1 sources and WebM for VP8 or VP9, because a VP9 track wearing an .mp4 extension plays in a browser and is turned away by QuickTime, by Premiere and by most phone galleries. The encoder is handed the source's own measured bitrate to spend, so the change in the byte count is the pixel count doing the work.

None of this involves a server. The clip is read inside the page, resampled and re-encoded by a Web Worker on your own machine, and handed back as a download.