Drop an MKV onto a video converter and hit go. Sometimes the result appears in five seconds. Sometimes a progress bar crawls for fifteen minutes. Same file type, same tool, wildly different waits. The reason is that "convert this MKV to MP4" is a category of task that hides two very different mechanical operations underneath. Which one runs is decided by what's inside your file - not by which one you'd prefer. (For the container-level story behind why "MKV" doesn't determine the answer, see MP4 vs MKV.)

#What a re-encode actually does

Re-encoding - the slow path - is exactly what it sounds like. The converter reads the source file, asks the decoder to reconstruct the raw pixels for every frame, then asks a different encoder to compress those pixels back into a new bitstream. A 30-minute 1080p clip is 54,000 frames. Every frame gets decoded, then re-encoded, then written to disk. Every audio sample gets the same treatment.

Modern video codecs are complicated. Decoding H.264 involves motion-compensated prediction, integer transforms, deblocking filters, and entropy decoding - several thousand CPU cycles per pixel. Encoding is worse: the encoder searches for redundancy between frames, evaluates dozens of prediction modes for each macroblock, and picks the one with the best rate-distortion trade-off. A single 4K frame can take a hundred million cycles to encode well. Multiply by 90,000 frames for a five-minute clip.

On a modern laptop CPU, software H.264 encoding runs in the neighbourhood of two to five times real-time for 1080p. That means a ten-minute clip takes two to five minutes to encode. Hardware encoders (the ones in your Intel iGPU, Apple Silicon, or NVIDIA GPU) go faster - often ten to twenty times real-time - but they're only available through platform APIs, not always exposed to every converter.

#What a remux actually does

A remux - the fast path - doesn't decode anything. The converter opens the source, reads the file's container header, and rewrites it into the target format's equivalent. The compressed video and audio bitstreams inside are copied byte-for-byte into the new file. No decoding. No re-encoding. No pixel work at all.

The result is bit-for-bit identical to the source, minus a few kilobytes of container overhead that MP4's indexing shakes out. A 500 MB file becomes a 498 MB file in a handful of seconds - the disk I/O is basically the only bottleneck. There's no quality loss because nothing about the picture or sound has changed.

This is why "convert MKV to MP4" on a normal MKV of a movie can finish faster than you can blink. Most MKVs carry H.264 video and AAC audio, exactly what MP4 accepts. The container change is a header rewrite; the streams inside are already MP4-legal. It's also why the iPhone-won't-play-my-MKV problem is fixable in seconds without any quality trade.

#Which one your file gets

Neither you nor the tool chooses. The rules are mechanical. MP4 accepts a specific list of codecs - H.264, HEVC, MPEG-4 Part 2, AV1 for video; AAC, MP3, AC-3, E-AC-3 for audio. If everything inside your source is on those lists, remux is available. If anything on the list is missing - the source has VP9, or Opus, or Theora, or Vorbis, or WMV3 - a re-encode is mandatory for that stream. The container can't hold what it can't hold.

By file type, in rough order of "how often you get the fast path":

  • Almost always remuxable: MOV (MP4's sibling), M4V (MP4 with an Apple extension), 3GP (MP4 profile), F4V (Adobe's MP4-adjacent), MTS / M2TS (H.264 in a transport stream), TS (H.264 or HEVC in a transport stream), and most MKV files.
  • Usually remuxable, sometimes not: FLV (post-2008 files are H.264; older ones use Sorenson / VP6), AVI (varies wildly by era - H.264 remuxes, DivX / Xvid remuxes as MPEG-4 Part 2, older MPEG-1 doesn't), and DivX-labelled files (MPEG-4 Part 2, which MP4 accepts directly).
  • Never remuxable to MP4: WEBM (VP9 + Opus by definition), OGV (Theora + Vorbis), WMV (Microsoft codecs), MPEG-1 / MPEG-2 program streams, VOB (DVD MPEG-2), GIF (indexed frames with no MP4 equivalent). Every one of these needs a full re-encode.

#How to tell before you commit

Any competent converter inspects the source before starting. Wave shows this explicitly on the screen after you drop a file: a "Fast copy" badge means remux, "Re-encode needed" means the slow path. If a converter doesn't tell you, look at the source: if it's MKV, MOV, MTS, or M4V, expect fast. If it's WEBM, OGV, WMV, or MPEG, expect slow.

Also worth knowing: some converters re-encode everything unconditionally, even when a remux would have worked. This is usually a design shortcut (writing one code path is easier than writing two), sometimes a business one (server-side converters charge by CPU seconds - the slow path bills more). If a converter takes ten minutes on a MOV that another tool finishes in five seconds, that's not your file, that's the tool.

#When the slow path is worth choosing anyway

Occasionally you actively want the re-encode. A source with a codec your target player struggles with (an MP4 containing DivX that your iPhone won't decode) benefits from re-encoding to H.264 even though a remux was technically possible. A large source you're shrinking for upload also needs re-encoding - a remux keeps the file the same size, because the streams inside are unchanged. And a very old source (variable-bitrate MP3 audio with drift, an interlaced MPEG-2) sometimes fixes long-standing playback bugs when it's rebuilt from raw samples.

But for the common "I need this to play on X" case, remux is almost always the right answer when it's available. It's faster, it's lossless, and there's nothing to configure. The container is the thing that changed. The picture and sound didn't need to.