Before reducing the resolution of a screen recording, decide which text the viewer must read. A smaller file is useful only if someone can still identify the error, copy the relevant command, or follow the interface. For a text-heavy clip, trimming idle time and adjusting compression at the original dimensions are good first experiments.
The following test isolates one part of that decision: what happens to a static interface when you preserve 1080p versus downscale it to 720p. It is part of a VideoBee promotion, prepared with AI assistance and a reproducible HTML fixture. All measurements were taken on October 27, 2026.
Give the viewer a task
“Looks sharp” is a vague acceptance criterion. A bug-report recording offers more concrete ones:
- Read the complete job ID, including underscores.
- Distinguish the retry delay from the retry count.
- Identify the HTTP status in the error message.
- Follow the pointer to the control being discussed.
Review the exported clip at the size people will actually use. A desktop preview enlarged to full screen can hide the fact that the same video is difficult to read inside a chat attachment or a narrow documentation column.
If the original text is already too small, increasing the application’s zoom before recording often helps more than changing the encoder afterward. Capture the relevant window or region so the important content occupies more of the frame.
A small test with the same interface in every frame
The fixture was a synthetic 1920 × 1080 HTML developer console. It contained 22-pixel code text, a long identifier, a status table, and a short readability checklist. No customer data was used.
Its screenshot was encoded into an eight-second, 30 fps H.264 clip. Three additional exports were made from that same source:
| Export | Frame size | Settings | File bytes |
|---|---|---|---|
| Source fixture | 1920 × 1080 | x264, CRF 18, medium | 128,733 |
| Local quality adjustment | 1920 × 1080 | x264, CRF 28, medium | 80,233 |
| Local downscale | 1280 × 720 | x264, CRF 18, medium | 76,091 |
| VideoBee Advanced | 1920 × 1080 | H.264, quality 21, Very fast | 87,782 |
The two local alternatives differed by just 4,142 bytes in this fixture. That is a reason to inspect the text before choosing the smaller one. It is not evidence that 1080p will always cost almost the same as 720p: static frames are unusually cheap to encode.
Actual decoded frames at one second. The 720p frame is displayed at the same apparent size as the 1080p frames. Open the image at full size to inspect the letter edges.
These crops preserve the real exported pixels. They are not a manually blurred before-and-after illustration. Inspect the long identifier, the underscores, and the colored letters; decide whether the differences matter for the viewer’s task.
There is no motion in this fixture and no audio track. It cannot tell you how much space a scrolling terminal, animated dashboard, webcam overlay, or narrated tutorial will need. Its purpose is to make a resolution tradeoff visible while keeping the content identical.
Reproduce the local comparison
To construct an equivalent static fixture from your own non-sensitive screenshot:
ffmpeg -loop 1 -i reference.png -t 8 -r 30 \
-c:v libx264 -preset medium -crf 18 \
-pix_fmt yuv420p -movflags +faststart source-1080.mp4
Create a smaller encode while retaining its dimensions:
ffmpeg -i source-1080.mp4 \
-c:v libx264 -preset medium -crf 28 \
-pix_fmt yuv420p -movflags +faststart keep-1080.mp4
Then create a separate downscaled candidate:
ffmpeg -i source-1080.mp4 -vf scale=1280:720 \
-c:v libx264 -preset medium -crf 18 \
-pix_fmt yuv420p -movflags +faststart downscale-720.mp4
These are experimental settings for a silent fixture. Keep the audio you need in a real recording and account for its size separately. The FFmpeg documentation and scale-filter reference describe the underlying encoding and resizing options.
The comparison changes both dimensions and quality settings. It is a comparison of two practical export candidates, not a study isolating the effect of CRF alone. For a controlled CRF experiment, keep the resolution, preset, frame rate, audio, and encoder version fixed.
Try a quality target before a hard file-size target
The VideoBee video compressor offers a Basic mode for a target size and an Advanced mode with codec, compression method, quality, and speed controls.
For the fourth row above, I uploaded the source fixture, selected Advanced Compression, used H.264 and Target a video quality, and kept the displayed defaults of 21 Good Quality and Very fast. The old-device compatibility checkbox stayed off. The downloaded file remained 1920 × 1080 and was 87,782 bytes.
That is a useful starting workflow when the text matters more than hitting a particular attachment limit. The VideoBee and local encodes used different presets and settings, so their sizes should not be read as a ranking of encoder efficiency.
When you do have a hard size cap, use it as a constraint after checking readability. If the readable version is still too large, shorten the recording or split distinct explanations into separate clips before pushing the quality lower.
Check a frame, then watch the whole clip
Frame inspection helps catch soft text, but it misses temporal problems. After selecting an export, watch the section with the fastest scrolling, the smallest important labels, and the densest pointer movement. Listen for missing or out-of-sync narration.
You can extract the same timestamp from each file for a repeatable visual check:
ffmpeg -ss 1 -i keep-1080.mp4 -frames:v 1 keep-1080.png
ffmpeg -ss 1 -i downscale-720.mp4 -frames:v 1 downscale-720.png
Compare the same region at the same apparent display size. Looking at a smaller 720p thumbnail next to a larger 1080p frame is not a fair readability check. Also keep the source recording: repeated re-encoding makes it harder to identify where a defect was introduced.
For the final pass, hand the clip to someone without the original context and ask them to identify the exact error or perform the step it demonstrates. Their answer is more useful than a file-size reduction percentage on its own.
Top comments (0)