I wanted a simple answer: how far can a screen recording be squeezed before the small text in it stops being readable. I got an answer, but the interesting part of the week was the three separate moments where my own setup nearly handed me a wrong one.
I am not an engineer by training, so a word on the vocabulary first. Resolution is how many dots the picture is wide and tall. Frame rate is how many pictures play per second. Bitrate is how much data each second of picture costs, and it is what really decides file size. Codec is the algorithm that turns the pictures into a file — H.264 is the usual one, VP9 and AV1 are newer. PSNR is a number you get by comparing the compressed picture to the source dot by dot, in dB, higher meaning closer to the source. Around 46 I could not tell the two apart at 3x zoom; at 26 the difference is obvious without zooming.
Everything ran in ImgIng (https://imging.ai/ ), whose video compressor works inside the browser tab. That was a practical choice rather than a loyal one: I ran the same clip through it a dozen-plus times, and with the network panel open I could see nothing leaving the machine, so there was no quota and no upload wait between attempts.
The source file was the first trap
My samples are built, not captured — a fake warehouse admin UI, invented brand, invented SKUs, small 11 to 13 pixel text in the tables. When I first rendered the main clip, 62 seconds at 1920x1080 and 30 fps, it came out at 18 MB. Then 10 MB. Then 13.5 MB. Synthetic frames are pixel-identical in the still areas, so the encoder skipped straight over them, and I had a "screen recording" nothing like the 300 MB files people actually complain about.
I ended up rendering it with every frame stored independently, no inter-frame prediction, near-lossless quality. That landed at 295.7 MB — the shape a screen recorder produces. It matters because part of the headline number comes from that choice. The default preset took it to 21.34 MB, which is 7.21% of the original, a 92.8% saving at PSNR 46.17. That percentage is only true for a near-lossless all-I-frame source. Quote it without that clause and it is marketing.
The percentage describes the footage
Same preset, nothing touched, two more samples: a slideshow-style meeting recording saved 40.7% at PSNR 43.38, and a clip where the whole screen changes every frame saved 45.9% with PSNR down at 26.52. Mostly-still pixels with text and a bit of local motion is a genre. Handheld video is not that genre, and the number does not travel.
The metric had a hole in it
Then I changed one knob at a time. Dropping 30 fps to 24 cut 14.4% of the size, and every quality number stayed put: PSNR 46.11 before, 46.11 after, text sharpness identical to two decimals. For about an hour I believed frame rate was free.
It is not free, my measurement was just blind to it. I sample frames at fixed wall-clock timestamps and compare each one as a still image, and 372 frames — a fifth of the clip — were simply gone. What you lose is motion continuity, and I had no metric pointing at it. I still do not. So the honest line is "14.4% smaller", full stop.
The last surprise was the one I expected least. Lowering resolution feels like the obvious saving, and on this clip it was the only step that damaged the small text, and at the 1280 setting it produced a larger file — 25.7 MB against 20.3 MB at native, 26.6% bigger, because the interface pairs that setting with a higher bitrate than the native one. At 854 the size finally dropped, and the SKUs were no longer readable. Meanwhile switching the output to WebM/AV1, touching nothing else, went from 20.3 MB to 6.4 MB with sharpness essentially unchanged. So: codec first, frame rate second, quality preset third, resolution last.
One clip, one machine, one browser, samples I built myself. I never tested what any video platform does to these files after upload, and that is probably the step that undoes half of this.
Top comments (0)