Does a stream copy shrink the file?

Barely. No picture data changes; size differences come from container overhead. Actual size reduction always requires re-encoding.

How much quality does one re-encode cost?

At sane settings (CRF 18-23) a single generation is visually indistinguishable; damage comes from starved bitrates or many stacked generations. Control those two and you are fine.

Why is the same tool sometimes fast and sometimes slow?

The tool picks the path by source codec: compatible codecs copy in seconds, legacy codecs re-encode for minutes. The speed gap is the two paths at work.

How it works 7 min read

Stream Copy vs Re-encode: Why Some Conversions Finish in Seconds

Moving H.264 video from MKV to MP4 can finish in seconds; moving an old AVI takes minutes. The difference is not file size — it is whether the job is a stream copy or a re-encode. Understanding the split lets you predict both the wait and the quality before you start.

Container vs codec

A video file is a container holding streams: MP4, MKV, MOV, AVI are containers (boxes); H.264, HEVC, VP9 are video codecs (goods); audio and subtitles are other goods. Colloquial "format" usually means container. Whether containers can swap losslessly depends on whether the codecs inside are supported by the target box.

Stream copy: new box, same goods

When the source codec is supported by the target container (H.264 from MKV into MP4), the conversion just moves the video, audio, and subtitle streams over untouched — no frame is recompressed. That is why it finishes in seconds with zero quality loss; that is the real meaning of "lossless conversion." The MKV-to-MP4 tool takes this path automatically when codecs are compatible.

Re-encode: rebuilding every frame

When the source codec is unsupported (old AVI codecs), or you need a different resolution, bitrate, or codec, every frame must be decoded and recompressed. It is slow and carries generational loss — small and invisible when parameters are sane, but real.

Seconds + zero loss = stream copy (codec-compatible container swap)
Minutes + slight loss = re-encode (legacy codecs, changed parameters)
Re-encode is not a dirty word: compression and resizing require it

Predicting your path before you start

Inspect the source codec and check it against the target container: compatible codec with unchanged parameters means a seconds-long lossless copy; legacy codec or changed parameters means a minutes-long re-encode. Knowing this up front stops you from mistaking normal work for a hang.