Re-encode vs Stream Copy: Why Conversion Sometimes Gets Slow or Blurry

At tools.beer we see the same complaint constantly: someone drops an .mp4, wants an .mkv or just the audio extracted, waits several minutes, and then notices the quality is a little worse.

Most people assume: "converting is just slow, and it's just blurry." It isn't.

The problem isn't that you converted — it's how. Did you re-cook the content (re-encode), or just change the plate (stream copy)? Those two operations are worlds apart. Get this wrong and you waste time and throw away quality for nothing.

1. The analogy: recook vs change the plate

Think of a media file as a plated dish:

• Re-encode (Transcode) = take the dish apart and cook it again. You break the finished dish back into ingredients (decode), then cook it with a new method (encoder) into another dish. You can change the flavor and portion, but it's slow, and every re-cook loses a little of the original (lossy).
• Stream copy (Remux) = same dish, just moved to a new plate. The food is untouched; you only swapped the container. It's nearly instant, and the taste is identical.

The one line to remember: stream copy changes the container; re-encode changes the content.

2. Stream copy: change the plate, not the food

In FFmpeg, stream copy is -c copy (copy all streams) or -c:v copy -c:a copy (copy video/audio only). What it does is dead simple:

1. Read the already-compressed audio/video packets from the source container;
2. Drop them, unchanged, into the new container;
3. Write the file.

There is no decode and no encode, so:

• It's extremely fast — the bottleneck is just disk I/O, and multi-GB files finish in seconds;
• Zero quality loss — not a single byte of the media changed, so picture and sound match the source exactly;
• File size is almost unchanged — you only swapped the wrapper.

What it can do: swap containers (mp4→mkv), extract one stream (pull audio out of a video), and cuts that don't re-encode.

What it cannot do: change resolution, change bitrate, change the codec, or apply filters — all of those require "breaking the dish back into ingredients" and "cooking again."

3. Re-encode: take it apart and rebuild — flexible but costly

Re-encode (a.k.a. transcode) is what most converters do by default:

1. Decode: expand the compressed data back to raw audio/video;
2. Process (optional): change resolution, lower bitrate, apply filters;
3. Re-encode: compress again with the target encoder (e.g. H.265, MP3);
4. Mux: wrap it into the target container.

The costs are obvious:

• Slow: encoding is CPU/GPU-intensive, often dozens of times slower than stream copy;
• Lossy: any lossy codec (H.264/H.265/AAC/MP3) loses a bit of information on every pass — quality drops irreversibly (unless you explicitly use lossless settings with matching codecs, which is rare);
• Variable size: you can shrink it by lowering bitrate, or accidentally make it bigger with bad settings.

It fits: mp4→mp3 (must re-encode, because the video stream is dropped and the audio changes from AAC to MP3), H.264→H.265 to save space, 4K→1080p to lower resolution, or transcoding old footage into a codec an old device can play.

4. The difference at a glance

5. Real bugs we hit

These aren't textbook examples — they are things we actually ran into building tools.beer's in-browser and desktop converters.

Bug 1: stream-copied audio still breaks if the container is wrong. Extract AAC from an mp4 with -c:a copy into a bare .aac, and you hit the same old problem from our container vs codec piece: a bare AAC stream has no duration metadata, so some players misread the sample rate and play it at half speed with double length (FFmpeg trac #5448). So even with stream copy, you must wrap the audio in a proper M4A container — the action is "copy", but the container is not optional.

Bug 2: stream-copied cuts start dirty. -c copy -ss 00:01:30 -to 00:02:00 looks like it trims, but it can only cut on keyframes (I-frames). If your start isn't a keyframe, the cut either jumps to the next keyframe (dropping the beginning) or pads with repeated frames. Frame-accurate trimming requires re-encoding.

Bug 3: why some tools.beer conversions are fast and some are slow. Our desktop build (native Tauri ffmpeg) "convert to mp4" path runs a real libx264 re-encode, so the wait is genuine re-compression. The pure container-swap path in the browser is essentially stream copy, so it's instant. Once you understand this, you won't mistake "the converter is lazy" for "the converter is slow."

Bug 4: many online converters re-encode by default. Whether you only wanted a new container or just the audio, they often re-encode anyway — slow, quality-dropping, and conveniently monetized via "queue boost" or "premium speed." You could have done it losslessly in a second with stream copy.

6. When to use which (decision checklist)

• Just swapping containers (mp4→mkv, mov→mp4) → stream copy;
• Extracting audio from video, and the target codec matches the source → stream copy;
• Quick trim where cut precision doesn't matter → stream copy;
• Changing codec (H.264→H.265), shrinking size, lowering resolution, adding filters, or moving to an incompatible format → re-encode;
• Video to pure audio (mp4→mp3) → must re-encode (video dropped, audio codec changes too).

Once this clicks, read how FFmpeg actually works and the "decode–encode" stage will suddenly explain why re-encode is the expensive part. To start from the top, see the complete guide to audio/video conversion.

Summary

• Re-encode = take apart and rebuild: change anything, but slow, lossy, CPU-hungry.
• Stream copy = swap the container only: fast, lossless, but can't change the content itself.
• Most "format changes" only need stream copy — don't re-encode for nothing.
• Stream copy has limits too: no codec/resolution change, and cuts align to keyframes.

Further reading

• Container vs Codec — explained in plain English
• How FFmpeg actually works (with diagrams)
• How to choose formats? MP4 / MKV / WebM / MOV
• Lossless vs lossy: what is the real difference?
• Walkthrough: what happens when you click mp4→mp3
• The complete guide to audio/video conversion

Want to try it now? You can convert MP4 to MP3 right in your browser.

References (authoritative sources)

Written by the tools.beer team, based on real lessons from building in-browser and desktop FFmpeg converters. Last updated 2026-08-20.