What transcode means: transcode vs encode vs remux vs compress

You have a 2.1 GB MOV off a camera, a client asking for "an MP4," and a cloud transcoder quoting you per output minute. Before you pay for a single second of that, run one ffprobe and check what's actually inside the file.

To transcode means to decode media that is already compressed and then encode it again, usually into a different codec, bitrate, resolution, or container. That is the whole definition. Encoding starts from raw, uncompressed frames. Remuxing moves the existing compressed streams into a different container without decoding anything. Compressing is a transcode whose goal is fewer bytes. Most requests that arrive worded as "transcode this" are remuxes, and a remux finishes in seconds and loses nothing.

Transcode vs encode vs remux vs compress, defined from the file's point of view

Transcode, encode, remux, and compress describe four different amounts of work done to your bits, and the difference is whether anything gets decoded:

Encoding is the first compression. Your phone encodes H.264 when it records. OBS encodes when it captures your screen. DaVinci Resolve encodes when it renders a timeline. There is no decode step because nothing was compressed yet.

Wikipedia's transcoding article defines it as decoding already-compressed media and encoding it again, and notes the loss that commonly comes with a lossy codec. HEVC to H.264 is a transcode. 4K to 1080p is a transcode. 12 Mbps to 4 Mbps is a transcode.

Remuxing, also called transmuxing, repackages the compressed essence into a different container without altering the encoded data, as the transmux entry puts it. VLC's documentation says the same: a container change with no re-encoding. MOV to MP4 is usually a remux. MKV to MP4 is often a remux.

Compression is not a fifth operation. "Compress this video" is a transcode request where the success condition is a file size rather than a codec. The command looks the same; only the target changes.

The check that tells you whether you need a transcode at all

Read the file before you decide anything. ffprobe will tell you the codec of every stream in JSON, and that single answer decides between a job that takes seconds and one that takes minutes and costs money:

ffprobe -v error -show_streams -of json input.mov \
  | jq '.streams[] | {index, codec_type, codec_name, profile, width, height}'

FFmpeg's documentation for ffprobe covers -show_streams, and codec_name is the field that matters. If it says h264 and aac and your target is MP4, you are done thinking. That combination copies straight across:

ffmpeg -i input.mov -c:v copy -c:a copy -movflags +faststart output.mp4

FFmpeg's manual is explicit about what copy does: it selects the copy "encoder," which is a stream copy with no decoding and no encoding, so it runs very fast and has zero quality loss, and it's the documented way to change container or stream count. The same manual states the default that catches people out: ffmpeg transcodes every audio, video, and subtitle stream unless you ask for -c copy. Leave the flag off and you've paid for a re-encode you didn't need.

A 2 GB H.264 MOV remuxed to MP4 on a laptop SSD finishes in a few seconds, because the work is disk I/O and box rewriting, not math on 50,000 frames.

When a copy will work, by container

What a container can legally hold is what decides whether a copy is possible. MDN's container guide lists MP4 as carrying H.264, HEVC, and AV1 video with AAC audio, which is exactly why an H.264 plus AAC MOV copies into MP4 without complaint: both containers already accept those streams.

WebM does not. The WebM container specification is defined around VP8 and VP9 video with Vorbis or Opus audio. An H.264 plus AAC source cannot be remuxed into WebM. That one is a real transcode, and -c:v copy will fail with an error about the codec not being supported in the output format rather than silently producing a broken file.

Four situations force a genuine re-encode:

Everything else is a container problem wearing a transcoding costume.

Why every vendor that explains transcoding to you bills for the re-encode

Vendor incentives here are structural, not sinister, and they explain why no streaming-vendor glossary ends with "check whether you can just copy the streams." Google Cloud's Transcoder API pricing meters per minute of transcoded video output, tiered by output resolution at $0.015 for SD, $0.030 for HD, and $0.060 for UHD, and the price is calculated for each video stream encoded. Build a five-rung ladder from one input and you are billed five times. AWS Elemental MediaConvert bills per minute of output content, prorated per second, using normalized minutes with multipliers for resolution, codec, and frame rate.

Both meters count output. A remux produces no encoded output, so it has no place in that business model, which is why the pages explaining transcoding arrive at an adaptive bitrate ladder and stop.

FFmpeg Micro meters differently. Billing runs on input duration, per second, with no rounding up to the minute, so a 10-second video costs 10 seconds, a 30-second trim pulled from a one-hour recording is billed as 30 seconds, and failed jobs are never billed. One input, billed once, whatever comes out. The pricing page has the arithmetic: one token buys 10 seconds of input, and the free tier is 200 tokens, roughly 33 minutes, with no card. Checking status, listing jobs, and downloading cost nothing.

Shipping one file at platform spec is the right default for most pipelines, and Video Encoding covers the encode step itself.

The cost of transcoding the same file twice

Generational loss is the reason the remux question matters beyond the invoice. Lossy codecs introduce artifacts on every encode and re-encode, and as generation loss describes, those artifacts accumulate: each pass encodes the previous pass's errors as if they were real detail, then adds its own.

Pipelines collect these passes without anyone deciding to. A camera encodes H.264. An editor renders an H.264 master. A normalization step transcodes it to a house spec. A platform transcodes it again on upload. That is four generations, and only the first one was unavoidable. Where a step in the middle could have been -c:v copy -c:a copy, skipping it is free quality.

The practical rule: keep the highest-quality master you have, do your real re-encode once, from that master, straight to the final spec, and copy streams at every step where the codecs already fit. Chaining two transcodes to reach one destination adds a generation of loss for nothing, so put both changes in a single pass.

The one-call version when you do need a real re-encode

When the probe says a re-encode is genuinely required, HEVC into MP4 for a platform that rejects HEVC, or 4K down to 1080x1920, the question becomes where it runs. A 2 GB input re-encoded with libx264 will occupy a CPU for minutes, which is why this step is the one that ends up in a queue, a Lambda that times out, or a Docker image somebody has to keep patched.

FFmpeg Micro takes the same job as a REST call. Submit, poll, download, no encoder on your machine:

curl -X POST https://api.ffmpeg-micro.com/v1/transcodes \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "inputs": [{ "url": "gs://your-bucket/1234567890-input.mov" }],
    "outputFormat": "mp4",
    "options": [
      { "option": "-c:v", "argument": "libx264" },
      { "option": "-crf", "argument": "23" },
      { "option": "-c:a", "argument": "aac" }
    ]
  }'

The response comes back immediately with a job ID and "status": "pending". Poll GET /v1/transcodes/:id until status is completed or failed, then call /download for a signed URL. The quickstart runs that whole cycle for you with a temporary key, and the same job works from n8n, Make, Zapier, or an AI agent over MCP.

Where this is the wrong tool: if your end product is an adaptive player with an HLS ladder served to thousands of concurrent viewers, you want a managed streaming platform that owns encoding, storage, and delivery as one meter, not a processing API. If your file only needs a container change, don't send it anywhere. Run the stream copy locally.

FAQ about transcoding, encoding, and remuxing

Is transcoding the same as converting a video?

"Converting" is the consumer word for both transcoding and remuxing, which is why conversion tools feel unpredictable. A converter changing an H.264 MOV to an MP4 may copy the streams in two seconds or re-encode them over ten minutes, and nothing in the interface tells you which one happened. Probing the output with ffprobe and comparing codec_name against the source is how you tell.

Does remuxing lose quality?

Remuxing loses no quality, because no video data is decoded or re-encoded. The compressed samples are read out of one container and written into another unchanged, so the video and audio payload is bit-identical and only the container metadata differs.

Why won't QuickTime or Safari play the file I just remuxed?

A remuxed HEVC file usually fails in Apple software because FFmpeg writes HEVC into MP4 tagged hev1 by default, and Apple's AVFoundation decodes only hvc1. The fix is metadata only, not a re-encode: ffmpeg -i in.mp4 -c copy -tag:v hvc1 out.mp4. A second common cause is a missing +faststart, which leaves the moov atom at the end of the file so a browser cannot start playback until the whole file downloads.

Do I get billed if a transcode job fails?

FFmpeg Micro never bills a failed job. Billing is metered on input duration at one token per 10 seconds, so a job that errors out on a corrupt input or an unsupported codec costs nothing, and status checks, job listings, and downloads are free on every plan including the free tier.

Can I mix copying and transcoding in one command?

You can copy one stream while transcoding another, and FFmpeg's documentation shows this directly with forms like -c:v libx264 -c:a copy. That pattern is useful when video needs a real re-encode but the AAC audio is already correct, because it skips an audio generation of loss and shortens the job.

If your next job is a container change on an H.264 file, the cheapest answer is the stream copy you can run right now on your own machine, no account needed. For the ones the probe says really do need re-encoding, Sign up free and submit them as jobs instead: no servers to run and no FFmpeg to install, called from your code, from n8n, Make, and Zapier, or from your AI agents, with a free tier for the first batch.