A 4-minute 1080p screen recording that weighs 360 MB looks like a compression problem. On the file I measured, one setting at capture time decided most of that weight. A still frame of a slide cost 50,002 bytes in the original and 77 bytes after a quality-based re-encode, and the small text scored almost identically in both.
The sample is synthetic, which limits how far the numbers travel. It's a home-built 4-minute mock lecture recording with page turns, pointer moves, a burst of typing and one scroll, 1920×1080 at 30 fps, encoded as H.264 at a constant 12 Mbps, 360.0 MB, no audio. The frames are screenshots of a page I wrote, so there's no noise, and for about 78% of the running time nothing moves. A real recording will be harder to compress. I picked the 12 Mbps myself. Neither Apple nor Microsoft documents a default bitrate or frame rate for its built-in recorder, and the Xbox capture page only says the quality setting controls resolution and bitrate. All of it is one pass per setting on an Apple M4 Mac with ffmpeg (x264), HandBrake and macOS's avconvert. 1 MB here is 1,000,000 bytes.
Constant bitrate pays for frames where nothing changed
Non-key frames in the still stretches have a median of 50,002 bytes, about the same as frames where text is being typed or the handout is scrolling. The encoder had 12 megabits to spend every second and spent them whether or not the screen changed. The still stretches held 71.1% of all bytes, roughly their share of the running time: the bytes followed the clock instead of the content.
Re-encoding the same file with x264 at CRF 23, preset medium and otherwise defaults, brought it to 5.2 MB, 98.5% smaller. The median still frame dropped to 77 bytes. Typing frames came in at 80 bytes, and only scrolling needed real money at 906. My reading, not isolated in a separate test, is that a still macroblock can be coded as a skip for a few bits, and constant bitrate throws that saving away by padding up to the target. On small English text at the 60-second mark, SSIM against the lossless master was 0.970 for the re-encode and 0.971 for the 360 MB original.
Keyframes carry the cost once still frames are free
After the re-encode the weight moves to keyframes. The 29 keyframes averaged 140,557 bytes each, so one of them is worth roughly 1,600 still frames, and together they held 79.4% of the video stream. Two camera clips from Wikimedia Commons (CC BY-SA, re-encoded) look the opposite way: 59.4% and 77.7% of their bytes sit in P frames. Presumably sensor noise leaves residual in every block even when the shot looks static; I didn't isolate that. The three slide flips didn't trigger a keyframe at all, and x264 coded each new slide as a P frame of 22 to 36 KB. My guess is that the rest of the screen stayed put, so prediction still paid off.
That makes the keyframe interval the lever for recordings. Stretching the keyframe interval from 2 seconds to 10 cut the recording from 18,065,145 to 4,402,121 bytes, 75.6% smaller, while the camera clip shrank only 5.0%. The price is seeking: to land on an arbitrary frame, the decoder works through about 150 frames on average instead of about 30. Text quality didn't move with the interval.
Fixed-rate re-encoding keeps part of the waste
The avconvert same-size H.264 preset returned 359,952,116 bytes, effectively the original. Its HEVC preset reached 60.5 MB at a fixed 2.0 Mbps or so, still about 11 times the CRF 23 file. HandBrake's Fast 1080p30 preset is quality-based and produced 6.0 MB with small-text SSIM 0.969. The browser-side data point was ImgIng https://imging.ai/ , whose video compression runs on local files inside a desktop browser and supports batch jobs. On its smart recommendation setting, H.264 came out at 20.2 MB with SSIM 0.969, the same text tier as HandBrake at roughly three times the size, and H.265 came out at 30.5 MB, larger than its own H.264. The page made no upload requests during these runs. How it picks its settings I can't tell from the outside.
The recorder setting decides most of the size
Then the control case. The same lossless frames went into the Mac's hardware H.264 encoder (VideoToolbox) with a 12 Mbps target but no constant-bitrate constraint, and came out at 23,737,333 bytes, about 0.79 Mbps. Same picture, same machine, about a fifteenth of the size. So not every screen recording is fat. It depends on whether the recorder writes a fixed rate or lets the content decide, and I didn't test which mode the stock macOS or Windows recorders actually use.
If your recorder offers a quality-based or variable-bitrate mode, pick it and stop thinking in megabits per second. If it only offers a bitrate, record at that and re-encode afterwards with CRF and a 10-second keyframe interval for anything viewers won't scrub through constantly. Before touching frame rate or resolution, run ffprobe on a recording you have and compare a still frame's size with a typing frame's. If they come out about the same, your bytes are going to the clock.
Top comments (0)