Audio and video: containers, codecs, and transcoding
Media conversion confuses people because the file extension describes the container while the quality and compatibility depend on the codec inside it. Two files both called .mp4 can hold entirely different codecs, and one may play on a device that refuses the other. Separating those two ideas explains most of what happens during conversion.
Containers versus codecs
A container is a wrapper. It holds one or more streams, plus the metadata that keeps them synchronised: timestamps, chapter markers, subtitles, cover art. MP4, MOV, WebM, MKV, and AVI are containers.
A codec is the algorithm that compresses an individual stream. H.264, H.265, VP9, and AV1 are video codecs. AAC, MP3, Opus, and FLAC are audio codecs.
The relationship is many-to-many, which is where the confusion comes from. An MP4 usually contains H.264 video and AAC audio, but it can legally contain H.265, or AV1. A WebM contains VP9 or AV1 with Opus or Vorbis. When a file will not play, the container is usually fine and the codec inside it is unsupported. This is also why changing a file extension never fixes a playback problem: the extension describes the box, and the box was not the issue.
Remuxing is free, transcoding is not
There are two fundamentally different operations, and the distinction determines both speed and quality.
Remuxing moves streams from one container to another without touching the compressed data. Taking the H.264 video and AAC audio out of a MOV and placing them in an MP4 is a copy operation: it is nearly instantaneous, uses almost no CPU, and is perfectly lossless. If your only problem is container compatibility, this is what you want.
Transcoding decodes a stream back to raw samples and re-encodes it with a different codec or different settings. It is slow, CPU-intensive, and always lossy when the target is a lossy codec. Converting MP4 audio to MP3 is transcoding, because AAC and MP3 are different codecs.
The quality consequence is worth being precise about. The second encoder cannot know which artefacts in its input are real content and which were introduced by the first encoder, so it spends bits preserving damage while discarding fresh detail. Each generation compounds. Always transcode from the highest-quality source available rather than from an intermediate copy.
Lossy audio, and when it stops being transparent
Lossy audio codecs use a psychoacoustic model. They identify sounds masked by louder sounds nearby in time or frequency and discard them, on the reasonable basis that they are inaudible in context.
For most listeners and most material this works remarkably well. MP3 at 128 kbps is around a tenth the size of uncompressed audio and is transparent enough for speech and casual listening. Modern codecs do better: Opus at 96 kbps generally beats MP3 at 128, and AAC sits between them.
Where lossy encoding becomes audible is on sharp transients such as cymbals and applause, where masking is weakest, and on sustained pure tones. It also becomes audible after repeated generations, which is why editing should happen in an uncompressed or lossless format with a single lossy export at the end.
Why browser-based media conversion is slower than a desktop tool
Media conversion in the browser is possible because FFmpeg has been compiled to WebAssembly. That is a genuine achievement and it comes with two structural costs.
The first is the download. The WebAssembly build is roughly 30 MB, fetched and compiled on first use. That is why the first conversion in a session pauses before anything visible happens, and why the second one starts immediately.
The second is threading. Multi-threaded WebAssembly requires SharedArrayBuffer, which browsers expose only to cross-origin isolated pages, and enabling that isolation blocks most third-party embedded content. Sites that need both end up on the single-threaded build, which runs several times slower than native FFmpeg on the same hardware.
The trade is straightforward: slower conversion, in exchange for your media never leaving the machine. For short clips that is an easy trade. For feature-length video it is not, and a desktop tool is the right answer.
GIF deserves its own warning
GIF is a 1987 image format that the internet adopted for short animation because it plays everywhere and autoplays silently. It is genuinely bad at the job.
Two limits drive everything. Each frame may use at most 256 colours, so photographic content bands visibly. And frames are compressed independently with an algorithm from the 1980s, with no motion compensation, so a GIF is routinely five to ten times larger than the video it came from while looking considerably worse.
A muted, looping, inline video element gives you the same silent autoplay behaviour at a fraction of the size and far better quality, and it works in every browser. Every major platform that historically served GIFs converts them to video behind the scenes. Use GIF only when the destination genuinely will not accept video.
Frequently asked questions
Why will my MP4 not play on this device?
Almost always the codec rather than the container. The device probably lacks support for H.265 or AV1. Transcoding the video to H.264 is the usual fix, at the cost of a re-encode.
Does renaming a file change its format?
No. The extension describes the container, and the actual data is unchanged. A renamed file will still fail if the codec inside it is unsupported.
Why is browser conversion slower than my desktop tool?
The WebAssembly build is single-threaded here, because multi-threading needs cross-origin isolation that would break embedded third-party content. Native FFmpeg also uses hardware acceleration that is unavailable in the browser sandbox.