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.

The bill

What one 30-minute 1080p clip costs a re-encoder

54,000 Frames decoded 30 min × 60 s × 30 fps
54,000 Frames re-compressed every one, from scratch
2Mpixels Reconstructed per frame 1920 × 1080
0 Of the above, on a remux nothing is decoded at all
The last tile is the whole article. A remux doesn’t do this work faster - it doesn’t do it.

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 on the order of a hundred million cycles to encode well. Multiply that by the 9,000 frames in a five-minute 30 fps clip, or the 36,000 in a twenty-minute one.

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.

Wall clock

Converting a 10-minute 1080p clip, three ways

Software encodeffmpeg on the CPU, ~3× real-time ~3 min 20 s
Hardware encodeGPU / Apple Silicon, ~15× real-time ~40 s
Remuxno encoder involved at all ~5 s
0time to finish3 min 20 s
Worked from the throughput ranges above, not from a stopwatch - your machine will land somewhere in the neighbourhood. The shape is the point: the remux bar is short because the work isn’t optimised, it’s absent, and no amount of faster hardware closes that gap.

#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”:

Sorted by outcome

Which sources get the fast path

Almost always a remux MP4-legal codecs already inside
MOV M4V 3GP F4V MTS / M2TS TS MKV

MOV is MP4’s sibling, M4V is MP4 with an Apple extension, 3GP is an MP4 profile, F4V is Adobe’s MP4-adjacent. MTS and TS carry H.264 or HEVC in a transport stream. Most MKVs are H.264 or HEVC with AAC.

Depends on the file’s age the extension does not settle it
FLV AVI DivX

FLV after about 2008 is H.264 and copies; older ones are Sorenson or VP6 and don’t. AVI varies wildly by era - H.264 copies, DivX and Xvid copy as MPEG-4 Part 2, an old MPEG-1 AVI does not.

Never a remux into MP4 the codec has no MP4 home
WEBM OGV WMV MPEG-1 / 2 VOB GIF

WEBM is VP9 + Opus by definition, OGV is Theora + Vorbis, WMV is Microsoft’s own codecs, VOB is DVD MPEG-2, GIF is indexed frames with no MP4 equivalent. Every one needs a full re-encode.

Note that the middle group exists at all. Two files with the same extension, made eight years apart, can take completely different paths - which is why a good converter inspects the streams rather than reading the filename.

#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.

Judgement call

Reaching for the slow path on purpose

Worth re-encoding
  • You need the file smaller. A remux keeps every byte of the streams, so it keeps the size. Shrinking means re-compressing.
  • The codec inside won’t play on the target. An MP4 full of DivX is a legal MP4 that an iPhone still refuses.
  • The source is broken in a way rebuilding fixes. Drifting VBR MP3 audio, interlaced MPEG-2, timestamps that jump.
  • You are changing resolution or frame rate. Both require decoding to raw frames by definition.
Not worth it
  • “To make it more compatible.” If the streams are already MP4-legal, the wrapper was the only problem.
  • “To clean it up.” Re-encoding a clean H.264 file makes it slightly worse, never better.
  • Because the tool only offers one path. That is the tool’s limitation being charged to your quality budget.
  • To change the file’s extension. That is a header rewrite, and it is free.
Re-encoding is a tool, not a penalty - but it is the one operation in this whole pipeline that can only lose information. Spend it when you are buying something with it.

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.