Transcoding Explained: From Mezzanine to Streaming Ladder

A camera or editor hands you one high-quality file. A streaming service needs many versions of it — different resolutions, bitrates, codecs, and container formats — all packaged so a player can adapt. The processes that get you there are easy to conflate, so let's pin down the vocabulary first, then walk the pipeline.

Transcode vs transmux vs transrate

• Transcoding fully decodes the video to raw frames and re-encodes it, often to a different codec, resolution, or bitrate. It is the expensive, quality-affecting operation. Going from a ProRes master to an H.264 720p rendition is transcoding.
• Transmuxing (remuxing) repackages the same encoded bitstream into a different container without re-encoding. Wrapping an existing H.264 elementary stream from MP4 into fragmented MP4 or TS segments is transmuxing — cheap, lossless, and fast.
• Transrating is a narrow case of transcoding that changes only the bitrate while keeping codec and resolution. Useful for fitting a stream to a tighter bandwidth target.

The distinction matters operationally: transmuxing is so cheap it can run just-in-time at the edge, while transcoding is heavy enough to dominate your compute bill.

The mezzanine (source) file

Production rarely transcodes from the original camera master for every output. Instead you create a mezzanine — a high-bitrate, lightly compressed intermediate (e.g. ProRes, or high-bitrate H.264/HEVC at CRF 16–18). It is large but fast to decode and visually near-lossless, so it serves as a clean, consistent source for all downstream renditions without repeatedly paying for the full-quality decode of a fragile master.

The encoding pipeline

A typical VOD transcode produces a bitrate ladder — several renditions at different resolution/bitrate pairs. A conventional ladder might look like:

• 1080p at ~5 Mbps
• 720p at ~3 Mbps
• 480p at ~1.5 Mbps
• 360p at ~0.8 Mbps
• 240p at ~0.4 Mbps

These figures are illustrative; per-title encoding (covered in the VOD architecture article) tunes them per piece of content.

FFmpeg: one rendition

A single 720p H.264 rendition with a capped VBR and segment-aligned keyframes:

ffmpeg -i mezzanine.mov \
  -vf scale=-2:720 \
  -c:v libx264 -profile:v high -preset slow \
  -b:v 3000k -maxrate 3300k -bufsize 6000k \
  -g 48 -keyint_min 48 -sc_threshold 0 \
  -c:a aac -b:a 128k \
  -pix_fmt yuv420p \
  720p.mp4

-g 48 with -sc_threshold 0 forces a keyframe every 48 frames (2s at 24 fps) regardless of scene cuts, so every segment can start on a keyframe — essential for clean rendition switching.

FFmpeg: multi-rendition in one pass

FFmpeg's split filter and multiple outputs let you produce the whole ladder from a single decode, avoiding repeated decoding of the source:

ffmpeg -i mezzanine.mov \
  -filter_complex "[0:v]split=2[v1][v2]; \
    [v1]scale=-2:720[v720]; [v2]scale=-2:480[v480]" \
  -map "[v720]" -c:v:0 libx264 -b:v:0 3000k -maxrate:0 3300k -bufsize:0 6000k \
  -map "[v480]" -c:v:1 libx264 -b:v:1 1500k -maxrate:1 1650k -bufsize:1 3000k \
  -map a:0 -c:a aac -b:a 128k \
  -g 48 -keyint_min 48 -sc_threshold 0 -pix_fmt yuv420p \
  -f null /dev/null

Packaging to HLS and DASH

Encoding produces renditions; packaging segments them and writes the manifests. FFmpeg can do basic HLS packaging directly:

ffmpeg -i 720p.mp4 \
  -c copy -f hls \
  -hls_time 2 -hls_playlist_type vod \
  -hls_segment_type fmp4 \
  -hls_segment_filename "720p_%03d.m4s" \
  720p.m3u8

Note -c copy: the segmenter is transmuxing, not re-encoding. For production you would typically use a dedicated packager (Shaka Packager, Bento4) to emit CMAF segments referenced by both an HLS .m3u8 and a DASH .mpd, so one set of media files serves every player. The trade-offs between those manifest formats are covered in HLS vs MPEG-DASH.

Hardware vs software encoding

• Software encoding (x264, x265, libvpx, SVT-AV1 on the CPU) gives the best quality per bit and the most control, at the cost of speed. It is the standard for VOD where you encode once and serve millions of times, so quality wins.
• Hardware encoding (NVIDIA NVENC, Intel Quick Sync, AMD VCE, Apple VideoToolbox) is dramatically faster and lower power but generally produces larger files at equal quality. It shines for live transcoding and high-throughput pipelines where latency and density matter more than squeezing the last few percent of efficiency.

A rule of thumb: encode VOD in software for quality, transcode live in hardware for speed and density.

Putting it together

Transcoding is the compute-heavy heart of every streaming workflow: take a mezzanine, fan it out into a bitrate ladder of codecs and resolutions, then package once into CMAF for HLS and DASH. Use the FFmpeg command builder to assemble these pipelines without memorizing every flag, and the media info inspector to verify the codec, profile, GOP, and bitrate of your outputs.

To understand the perceptual choices behind the encode, revisit Video Compression Basics; to see where this pipeline sits in a full system, continue to VOD Streaming Architecture.