Generational loss, in plain terms
A lossy codec like H.264 keeps a video small by discarding information the encoder judges you are unlikely to notice. Decoding and re-encoding that same video discards a little more. Do it again and again and quality slides toward mush — the same way a photocopied photocopy fades. This is generational loss, and a careless merge tool inflicts exactly one generation of it on every file it touches.
What stream copy actually does
Stream copy skips the decode-and-re-encode round trip entirely. It takes the already-compressed video packets and the already-compressed audio packets and writes them straight into a single container, unchanged. The output is bit-for-bit the same video the source served — no second generation, no lost detail — and because no codec work happens, it is near-instant and costs almost no CPU.
When we do re-encode (and why it is only for MP3)
Re-encoding is the right tool only when the goal genuinely requires it — for example extracting the audio and turning it into an MP3, which is a different format with its own trade-offs. That is the one place we reach for a real encode. Everything that can be a stream copy is a stream copy, because the default should always be to preserve what the source already paid to compress.
The CPU and battery argument
Encoding a long video can pin every core of a laptop for minutes and drain a battery. Stream copy finishes in seconds and barely registers. For a tool whose whole job is to get out of your way, spending thirty seconds of silence to save a task that could finish instantly is not a technical detail — it is a user-respect decision.
The rule we hold to
Never degrade what you were not asked to change. If the user wanted the video, they should get the video — the exact one, not a slightly sadder copy that merely looks similar at a glance. Restraint about what you touch is as much a part of quality engineering as care about what you build.