Codec vs Container

Take one 1080p clip, repackage it as .mp4, .mov and .mkv, and pull the raw H.264 stream back out of each. All three hash to the same SHA-256. The wrapper changed and the picture data didn't move a bit, which is the whole difference in one test: a container just holds streams, and swapping it costs nothing unless the codec inside also has to change.

When can you just swap the container?

Swap the container and stop there when:

• The codec inside is already something the destination container accepts. H.264 or H.265 video goes into MP4, MOV or MKV without complaint.
• You just need the file to open somewhere else, not to get smaller or look different.
• Convert MKV to MP4 or convert MOV to MP4 and FileFlip copies the encoded stream instead of decoding and re-encoding it, which is why it finishes almost instantly.

Re-encode instead when:

• You need the file smaller. Bitrate lives on the codec side, not the container. Making a video file smaller for email covers the actual controls.
• The destination container can't hold what you have at all. MP4 has no slot for Apple's ProRes, and WebM will only take VP8, VP9 or AV1.
• The device on the other end can't decode your codec, even though it opens the container fine. That's a codec gap wearing a container-shaped disguise.

Codec vs container at a glance

What does a container actually store?

A container is a wrapper: one or more compressed streams, an index so a player can seek without decoding from the start, and whatever metadata the format allows, subtitle tracks, chapter markers, a colour profile. None of that is the picture or the sound. It's bookkeeping around them.

MKV's row explains why it exists at all: no cap on tracks or codecs, which is what lets it hold several subtitle languages and multiple audio mixes that MP4 either drops or can't accept in the first place.

What does the codec do?

The codec is the algorithm that turns raw pixels or samples into the compressed bytes a container carries, and back again. H.264, H.265 and AV1 do that job for video; AAC, Opus and FLAC do it for audio. A player needs a decoder for the specific codec inside your file, and the container opening fine tells it nothing about whether that decoder exists, which is the split behind most "won't play" reports.

Why does the .mp4 extension tell you almost nothing?

Because .mp4 only promises the wrapper, and the wrapper accepts several codecs that behave completely differently once a player tries to decode them. Ask FFmpeg what family a .mp4 actually belongs to and it answers mov,mp4,m4a,3gp,3g2,mj2: five extensions sharing one box structure, because MP4 was standardised from Apple's own QuickTime format. An .mp4 and a .mov holding the same H.264 stream are the same bytes in a differently labelled wrapper.

Two .mp4 files can be worlds apart in practice. One holds H.264, which every phone, browser and TV sold in the last decade decodes in hardware; the other holds H.265 or AV1, which plenty of that same hardware still can't touch. The extension doesn't distinguish them. Only opening the file does.

How do you find out what's actually inside a file?

The container's own properties won't tell you. The Properties dialog on Windows or Get Info on a Mac reports the file size and the extension, not the codec.

MediaInfo is a free, open-source tool for Windows, Mac and Linux built for exactly this: point it at a file and it lists the container, then the video codec and the audio codec separately. If you're comfortable at a command line, ffprobe -show_streams yourfile.mp4 prints the same thing, and it's the tool FileFlip's own converters are built on, so what it reports is exactly what decides whether a browser or a device can play the file.

Does changing the container actually fix a file that won't play?

Only when the problem was the container. We tested both directions on the same clip to see where the line actually falls.

First, the identity check. We remuxed a 10-second, 1920x1080 H.264 clip into .mov and .mkv with FFmpeg's -c copy, which copies the encoded stream instead of decoding it, then extracted the raw H.264 stream back out of the source, the .mov and the .mkv and hashed each with SHA-256. All three came back aee8f069b715..., identical. Nothing about the picture data changed; only the box around it did.

That copy is also why a straight container swap is fast. Across three runs, remuxing the clip took 0.10 seconds. Re-encoding the same clip with libx264 at 5 Mbps took 2.10 seconds, about 20 times longer, because a re-encode has to decode and recompress every frame instead of copying bytes.

Then the boundary. We tried remuxing that same H.264 stream into a .webm file, and FFmpeg refuses outright: "Only VP8 or VP9 or AV1 video and Vorbis or Opus audio... are supported for WebM." No amount of copying gets H.264 into a container whose own specification doesn't allow it.

Renaming exposes the same line from the other side. We took that .mkv file and renamed it to .mp4 without touching a byte inside it. Ask FFmpeg to guess the format from the actual content and it still reports Matroska correctly, extension ignored. Force it to read those same bytes specifically as MP4, which is what a player that trusts the extension does, and it fails immediately: "moov atom not found." The bytes never changed. Only the label did, and the label alone isn't enough to make an MP4 reader find an MP4 inside.

What do you lose when the codec actually has to change?

Whatever the encoder discards on the way, and it's a one-way trip. Re-encoding is a lossy step, the same kind covered in lossy vs lossless compression, and it's exactly the step a plain container swap skips.

The container swap itself can still cost you something the codec had nothing to do with. Subtitle formats like ASS and PGS, common in MKV, have no MP4 equivalent, so they either get converted to a format MP4 accepts or dropped entirely. A track MP4 simply has no slot for, a second commentary audio track, a chapter menu, goes the same way. None of that is the video degrading. It's the wrapper being smaller than the one you started with.

Common questions

Is MP4 a codec or a container?

A container. MP4 wraps whatever video and audio streams it's given, most often H.264 or H.265 with AAC audio, but the format itself does no compressing. Two MP4 files can hold completely different codecs and behave completely differently on the same device.

Can renaming a file change its container?

No. Renaming a .mkv to .mp4 changes the label, not the bytes inside. Our own test above shows why that matters: forcing an MP4 reader onto genuine Matroska bytes fails with "moov atom not found," because the reader is looking for a specific box structure that was never written. Only an actual remux repacks the streams into a real container of that type.

Why won't my MKV file play on a smart TV or game console?

Usually because that device never added a Matroska demuxer, not because of the codec inside. Plenty of hardware players decode H.264 and H.265 fine when the same streams arrive in an MP4, and simply have no code path for reading Matroska at all. Converting MKV to MP4 fixes this instantly when the codec is already one MP4 accepts, since it's a remux rather than a re-encode.

Does converting MOV to MP4 lose quality?

Not when the video is already H.264 or H.265, which our hash test above confirms directly: the stream comes out byte-identical, because MOV and MP4 share the same underlying box structure. It only becomes a real re-encode, with the quality cost that implies, when the source is a codec MP4 can't hold, ProRes being the common one out of a camera or an editing timeline.

What codec should I use if I want a file to play everywhere?

H.264 in an MP4. It has hardware decoders in essentially every phone, browser, game console and smart TV made in the last decade, which is a wider net than any newer codec, including H.265 and AV1, currently reaches.

Convert between them

FileFlip converts MKV to MP4 and MOV to MP4 entirely in your browser, on a WebAssembly build of FFmpeg. Nothing is uploaded, there's no account, and when the codec inside is already one MP4 can hold, the conversion is the same stream copy this page measured, not a re-encode. The video converter covers every other container pair.

See the MP4, MKV and MOV format references for what each container can and can't carry.

How we measured this

• Source clip: a 10-second, 1920x1080, 30 fps H.264 segment of Big Buck Bunny (Blender Foundation, CC BY 3.0), the same clip used in our video file size measurements.
• Remuxing: ffmpeg -i source.mp4 -c copy output.mov and the same command for .mkv, which copies the encoded stream without decoding it.
• Hash check: extracted the raw H.264 stream from the source, the remuxed .mov and the remuxed .mkv with ffmpeg -c copy -bsf:v h264_mp4toannexb -f h264, then hashed each with shasum -a 256. All three matched.
• Timing: three runs each of the remux and of a re-encode to libx264 at 5 Mbps, using /usr/bin/time, median reported. Absolute seconds are specific to this machine; a slower or faster CPU moves both numbers, not the ratio between them.
• WebM rejection: ffmpeg -i source.mp4 -c copy output.webm against the same H.264 source, which FFmpeg refuses at the container-writing stage.
• Rename test: copied the remuxed .mkv to a .mp4 filename with no other change, then read it once with FFmpeg's default format probing and once forcing -f mp4 specifically.
• Tools: FFmpeg 8.1.2 on macOS.
• Caveat: one clip and one codec is a single data point. The identity and refusal results follow from how stream copying and container specifications work, and hold regardless of content, but the exact timing ratio will shift with a different codec, resolution or machine.