What a screen recorder actually does
A screen recorder re-films your display. It captures rendered frames in real time, re-encodes them on the fly with whatever encoder and settings it ships, and re-compresses the audio passing through your system. Every stage is lossy, and every stage sits on top of a source the platform already compressed once.
Three things the recording loses
The damage is consistent across tools, because it comes from the method rather than the implementation:
- Bitrate: playback streams are tuned to your connection — often a quarter of the source file's rate.
- Detail: dropped frames and motion blur appear whenever the capture cannot keep up.
- Audio: system-audio capture re-compresses the track and frequently drifts out of sync on long clips.
What a source-file download delivers
The source file is the bytes the platform stored: the creator's upload after a single platform encode. What a second encode costs is measurable. We passed a 1080p H.264 source through x264 in veryfast mode — the profile a recorder needs when it has to encode in real time — and scored the result against the original with VMAF, where 100 means an identical copy:
- 8 Mbps: VMAF 97.0, worst frame 95.0 — 12.0 MB for 12 seconds.
- 2.5 Mbps: VMAF 90.1, worst frame 86.2 — 3.7 MB.
- 0.8 Mbps: VMAF 61.6, worst frame 52.0 — 1.2 MB.
The interesting part is not that re-encoding costs quality — it is where the loss lands. At 2.5 Mbps the copy still scores 90 and looks close to the original. At 800 kbps it collapses to 62, and the worst frame drops to 52: that is the frame carrying the most detail, which in practice means text, foliage or a fine gradient. A recorder aiming at a 1080p display usually lands in the second range, which is why recorded on-screen text looks soft while flat backgrounds look perfectly fine.
When a recorder is still the answer
Recorders win in exactly one case: content that has no file representation — DRM-locked streams, live events you cannot pause, or an interface you are documenting for a tutorial. For anything with a public URL the source file wins on quality, sync and speed, because a download moves the file at its own bitrate while a recording must run in real time.
Troubleshooting recordings
- Choppy capture: the CPU was saturated — lower the recorder's resolution or frame rate.
- Audio out of sync: system-audio capture drifted; a source download avoids it entirely.
- The file is enormous: re-encoding at high settings ballooned the size.
- The result is blurry: the source was already low-bitrate, and recording cannot add detail.
Why frame timing is the harder problem
Bitrate is the damage you can measure; timing is the one you notice. A recorder captures the display at its refresh rate, not the file's frame rate, so a 30 fps source shown on a 60 Hz screen is captured as 60 near-identical frames. That is harmless on its own — but the capture has to keep up, and when it cannot, frames are dropped instead of duplicated.
- Duplicated frames: the encoder spends bitrate describing frames that did not change, and the picture gets softer for it.
- Dropped frames: a busy CPU skips captures, and the motion stutters in a way no bitrate can repair.
- Audio resampling: capture routes sound through the system mixer, which may resample 48 kHz to 44.1 kHz and drift over a long clip.
None of these appear in a quality score, because VMAF only compares frames that exist. A recording that lost a third of its frames can still score well on the two thirds it kept — which is why "sharp but stuttering" is such a common result, and why a download that never re-timed anything starts from a better place.
Frequently asked questions
- Is a recorder ever better? Only for DRM-protected, live, or otherwise file-less content.
- Why is a source download faster? It transfers at the file's bitrate instead of real time.
- Can I improve an existing recording? Slightly, but lost quality cannot be recovered.
- Does Downer re-encode? No — it returns the platform's stored source.