Converting MOV to MP4 and Other Video Formats Without Wasting Quality

Container or codec: what a video format really is

A file extension names the container: MOV, MP4, MKV, WebM, M4V. The container is a wrapper that holds streams and the timing that keeps them in sync. Inside are the streams themselves, compressed with codecs: H.264, HEVC, VP9, AV1 or ProRes for the picture; AAC, Opus, MP3, AC-3 or uncompressed PCM for the sound.

Converting a format can mean two very different operations. Changing only the container is called remuxing. Changing the codec is re-encoding. Most quality problems and slow conversions come from re-encoding a file that only needed a new container. The browser muxing article goes deeper into how containers and streams fit together; this article sticks to getting your file into the format you need.

Run ffprobe -hide_banner input.mov to see what is inside. Lines such as "Video: h264" and "Audio: aac" tell you a remux will almost certainly work. "Video: prores" or "Audio: pcm_s16le" tell you something will need converting.

Remux when the codecs already fit

MOV and MP4 come from the same family of file formats, and an iPhone or screen-recorder MOV usually holds H.264 or HEVC video with AAC audio, all of which MP4 supports. The conversion is: ffmpeg -i input.mov -c copy -movflags +faststart output.mp4

The -c copy option copies every stream as is, so a two-hour file converts in seconds and the output is bit-for-bit the same picture. The faststart flag moves the index to the front of the file so web players can start playback before the whole file downloads.

Two refinements come up often. For HEVC video that must play in Apple's apps, add -tag:v hvc1, because some players expect that codec tag; the HEVC compatibility article explains why. And if ffmpeg complains about a data or timecode stream, keep only video and audio with -map 0:v -map 0:a in place of copying everything.

Simply renaming .mov to .mp4 sometimes plays, because the structures are similar, but it is not a conversion and some apps reject the result. Remuxing costs seconds, so do it properly.

Re-encode when they don't, and what it costs

Re-encoding is needed when a stream's codec isn't supported by the target container or by the device that will play it. The common cases are:

• ProRes or DNxHR video from an editing export, which MP4 doesn't carry; re-encode to H.264 or HEVC.
• Uncompressed PCM audio in a camera or screen-recorder MOV, which many MP4 tools and players won't accept; re-encode just the audio to AAC.
• VP9 or AV1 video from a WebM, when the destination expects H.264.
• AC-3, DTS or FLAC audio in an MKV, when the player only handles AAC.

Re-encoding always loses some information when the target codec is lossy, and you control how much. With H.264 in ffmpeg, the CRF value sets quality: lower numbers mean higher quality and bigger files, and values around 18 to 23 are a common range, with 18 hard to tell apart from the source for most footage. The preset (from veryfast to slow) trades encoding time against file size at the same quality. Re-encoding never improves a file: converting a blurry, low-bitrate video at a high setting just makes a bigger blurry video.

When only one stream needs changing, re-encode only that one. ffmpeg -i input.mov -c:v copy -c:a aac -b:a 192k output.mp4 copies the picture untouched and converts only PCM audio to AAC. That is much faster than a full re-encode and keeps the video lossless.

Conversion recipes by format

MOV with H.264 or HEVC and AAC to MP4

remux with -c copy

MOV with PCM audio to MP4

copy video, re-encode audio to AAC

MOV with ProRes to MP4

re-encode video to H.264, audio to AAC

MKV with H.264 and AAC to MP4

remux; drop or convert subtitle tracks

MKV with AC-3, DTS or FLAC audio to MP4

copy video, re-encode audio to AAC

WebM (VP9 or AV1, Opus) to MP4

re-encode to H.264 and AAC for wide playback

MP4 to WebM

re-encode to VP9 or AV1 with Opus

MKV files often carry subtitle tracks in formats MP4 can't hold. Add -c:s mov_text to convert text subtitles into MP4's own format, or -sn to drop them. Image-based subtitles, such as those ripped from discs, can't be converted this way at all. And because ffmpeg by default picks only one video, one audio and one subtitle stream, add -map 0 when you need every audio track to survive.

For WebM to MP4 with broad compatibility, a typical full conversion is ffmpeg -i input.webm -c:v libx264 -crf 20 -preset medium -c:a aac -b:a 160k -movflags +faststart output.mp4. Going the other way, ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 32 -b:v 0 -c:a libopus output.webm produces a WebM, slowly; VP9 encoding is much slower than H.264.

Converting without a terminal

HandBrake is a free converter for Windows, macOS and Linux. It always re-encodes, with presets for common devices, and outputs MP4, MKV or WebM. It is a good choice for ProRes or WebM sources that need a full conversion, and a poor one for a MOV that only needs a new container.

LosslessCut can remux: open the file, choose MP4 as the output format and export, which copies the streams like ffmpeg's -c copy. VLC's Convert/Save dialog re-encodes using profiles, and QuickTime Player's Export As options re-encode to Apple presets. Online converters work too, but they upload the whole file to someone else's server, which matters for confidential footage and for multi-gigabyte files on slow connections. Menus change between versions, so check each app's current documentation.

A conversion routine that avoids surprises

1. Keep the original file untouched, and convert into a new file name.
2. Inspect the streams with ffprobe or MediaInfo and note the video codec, audio codec, number of audio tracks and any subtitle tracks.
3. Decide what the destination needs: a specific container, a codec a device can play, or just a file a tool will accept.
4. Try a remux first with -c copy. If it succeeds and plays, stop there.
5. If ffmpeg reports that a codec isn't supported in the container, re-encode only that stream and copy the rest.
6. Re-encode the video only when the codec itself is the problem, using a quality-based setting such as CRF rather than a fixed low bitrate.
7. Play the beginning, middle and end of the result, and check sync, all audio tracks and the duration against the original.

Example: a ProRes master that needs a web copy

ffprobe shows ProRes video and PCM audio, so a remux to MP4 won't work. For the website, the editor runs HandBrake with an H.264 preset at a high quality setting and gets a file of a few hundred megabytes that looks the same at normal viewing distance.

For the translation, no conversion is needed at all. MOV is an accepted input, and the browser reads the audio locally instead of uploading 15 GB. The one caution is memory: on a low-memory laptop, a very large master may come back as a translated audio file to download rather than a merged video. In that case, translating the H.264 web copy produces the merged video more easily, and since the soundtrack is identical, the translation is the same.

Mistakes that make conversions worse

• Re-encoding a file that only needed a remux, which wastes time and quality.
• Converting the same file repeatedly between formats. Each lossy re-encode adds artifacts; always convert from the original.
• Losing extra audio tracks or subtitles because only the default streams were mapped.
• Converting iPhone HDR video to standard H.264 without tone mapping, which can leave colors washed out or too dark. HandBrake and editors have HDR-aware options; check their documentation.
• Choosing a fixed low bitrate to save space, which breaks up fast motion and screen text.
• Assuming a conversion fixes sync problems. Remuxing preserves the timing; if a source drifts, it usually needs a different fix, especially with variable frame rate recordings.

Which formats mydubly takes without conversion

mydubly accepts MP4, MOV, WebM, MKV and M4V video, and MP3, WAV, M4A, AAC, OGG and FLAC audio, up to 2 hours per file. For those formats, converting first is usually wasted effort: the browser decodes the audio locally and sends only compressed audio chunks, so the container and the size of the picture stream don't affect the upload. Formats outside the list, such as AVI, WMV, FLV or MPEG transport streams, need converting to MP4 first, and a remux with -c copy is often enough when the codecs inside are H.264 and AAC.

For the translated video, mydubly keeps your picture exactly as it is and swaps in the new audio track, so it never re-encodes the video as part of the job. If the video codec can't go into MP4, the result is delivered as MKV. In other words, there is no need to convert a WebM or MKV source to MP4 just to get a translated version; convert afterwards only if the destination platform requires MP4. The large files article covers what happens with very large sources.

Where to go from here

Check what is inside the file before converting anything, and remux whenever the codecs allow. If the file is already an accepted format and you only need a translation or subtitles, open the video translator with the original. For format-specific transcription notes, see MOV to text.