Appendix H: Delivery & Codec Reference

The Rosetta Stone for getting a finished piece out of your software and into the world at full quality — Chapters 3 (codecs), 23 (social specs), 33 (loudness), and 36 (export and delivery) compressed into tables you can check the moment before you hit Export. It assumes those chapters taught you the why; this is the what, the number, and the spec to match. The single idea beneath all of it: delivery is a spec-matching craft (Chapter 36) — hand each destination a file built to its recipe, keep one pristine master you re-derive everything from, and caption every deliverable.

⚠️ Read this before you trust any number below. Every platform figure in this appendix — resolution, bitrate, loudness, caption format — is typical, at the time of writing. Platforms revise their published specs constantly and without notice: they change recommended bitrates, add codecs (AV1 is arriving as you read this), shift aspect ratios, and adjust loudness targets whenever they like. A spec you memorize today is wrong next year. These tables teach you the shape of each destination and the vocabulary to read its spec — they are not a substitute for the platform's own current published guidance, which you must confirm for anything that matters (a paid job, a broadcast delivery, a client handoff). The durable skill is knowing that a spec exists, that it moves, and where to look up today's — not the digits. See Appendix J (Resources & Communities) for where each platform publishes its live spec.

Notation used throughout: codecs by name (H.264, H.265/HEVC, ProRes, DNxHR, AV1); containers by extension (.mp4, .mov, .mxf); data rate in megabits per second (Mb/s); resolution as name or pixels (1080p, 4K / UHD 3840×2160, 1080×1920); aspect ratio as a ratio (16:9, 9:16, 4:5, 1:1); loudness in LUFS (whole-program integrated) with the peak ceiling in dBFS/dBTP. Note the unit trap from Chapter 3: bitrate is megabits (Mb/s); card/drive speed is megabytes (MB/s) — divide Mb/s by 8 to compare.

The whole appendix in one line. For almost everything you ship: deliver H.264 in an .mp4, matched to the timeline's resolution and frame rate, at a generous bitrate, mastered to ~-14 LUFS for streaming, captioned; keep a ProRes (or DNxHR) .mov master you derive every version from; and watch the exported file, start to finish, on a phone and a big screen before anyone else does. Everything below is detail on those moves.

H.1 Delivery & mastering codecs — what to encode into

A codec is how the picture is compressed; the container/wrapper (§H.2) is the box it ships in. Codecs split into two families you already know from Chapter 3: delivery codecs make small, universal files that are hard to edit (what you ship), and editing/mastering codecs make large, near-lossless files that cut smoothly (what you keep). Match the codec to the job, not to what sounds impressive.

The one-sentence rule that covers most of your career: .mp4 with H.264 for delivery to people and platforms; .mov with ProRes 422 HQ for the master you keep.

H.2 Containers / wrappers — the box, not the contents

The container is what the file extension names. It is not the codec — a .mov can hold ProRes or H.264; a .mp4 usually holds H.264 or H.265 (Chapter 3, §3.1). On delivery the choice is mostly about compatibility, and it follows the codec almost automatically.

H.3 Platform delivery specs — the shape of each destination

This is the table other chapters point here for. Read it across, not down — each row is a personality, not a law.

⚠️ TYPICAL VALUES, AT THE TIME OF WRITING — ALWAYS CONFIRM THE PLATFORM'S CURRENT PUBLISHED SPEC. The numbers below teach the shape of each destination. They change often and without notice. For any delivery that matters, pull the current figure from the platform's own help pages (see Appendix J) — do not deliver a paid or broadcast job on a number remembered from this page.

Four durable reflexes fall out of that table:

• YouTube is forgiving. Upload a clean, generous, high-bitrate file and let it re-encode (§H.5). Your -14 LUFS mix arrives about right because the platform normalizes toward that neighborhood.
• Vertical/feed social is aggressive and sound-off. 9:16 or 4:5, subject and text inside the safe zones (Chapter 23), and burn the captions in — a caption a viewer must switch on is a caption nobody switches on.
• Broadcast runs by a different book entirely. A quieter, tighter loudness standard, an exact codec and frame rate, a required caption format, and technical furniture (bars, tone, slate, head/tail black). You read the delivery document and match it line by line — memorization is useless here.
• The client spec is usually missing. Your move is twofold: ask ("where will this live — web, social, a trade-show screen, broadcast? do you need the editable master?"), and absent an answer, deliver a safe universal file (1080p/4K, H.264, .mp4, generous bitrate, ~-14 LUFS) — while keeping the master, because "can you also send it for TV / the big screen?" always comes.

H.4 Master vs deliverable — keep one pristine copy, derive the rest

The single habit that most separates a professional workflow from an amateur one, and it is nearly free. Compression is lossy and permanent (Chapter 3): every encode throws detail away for good. So you never make a deliverable from another deliverable — that stacks a second lossy squeeze on the first (generation loss, the photocopy-of-a-photocopy). You make one master and derive every version from it.

FIGURE H.1 — One master, many deliverables (derive from the master, never from a deliverable)

   LOCKED TIMELINE ─► [ THE MASTER ]  ProRes 422 HQ / DNxHR HQX · .mov · full res/fps
   (color, mix,        full quality · no burned-in captions · ARCHIVE THIS (Ch.37)
    graphics final)              │
             ┌───────────────────┼───────────────────┐   ← re-render from the TIMELINE,
             ▼                   ▼                   ▼     or transcode from the MASTER —
     [ YouTube 16:9 ]    [ Social 9:16 ]     [ Client .mp4 ]   NEVER export one deliverable
      H.264 .mp4          H.264, burned-      1080p/4K H.264    from another (generation loss).
      + sidecar .srt      in captions         (+ master if asked)

Two honest notes. (1) Re-rendering each deliverable from the timeline is theoretically best (every export is first-generation, and you can re-color or reframe properly along the way); transcoding from the master is fine too, since the master is near-lossless. Both beat the amateur move of exporting one lossy file from another. (2) If storage is genuinely tight, a high-bitrate H.264 master is far better than no master — the principle survives the budget: keep the best single copy you can afford, and derive from it.

H.5 Bitrate guide — how hard to compress on the way out

Delivery bitrate is how much data, in Mb/s, the encoder may spend per second of finished video. Higher = less thrown away = fewer of Chapter 3's artifacts (banding in graded gradients, macroblocking in shadows, smearing on motion) surviving into the delivered file. Two modes: restrict to a bitrate (name the number — use it when a spec dictates one), or constant quality (name a quality level, let the bitrate float — often smartest for your own uploads, since it spends data where the picture needs it).

The counter-intuitive rule: upload more than the platform will keep. Every big platform re-encodes your upload into its own formats — you can't stop it. So why upload high? Because a re-encode is only as good as the file it starts from. Hand it a clean, generous file and its re-encode has quality to work from (result: sharp). Hand it a stingy, already-damaged file and it compresses your artifacts, stacking new damage on old (result: mush). You are not fighting the re-encode — you are feeding it.

When to raise it: a heavy grade (smooth gradients band first), lots of fine motion (grass, water, crowds, confetti), fine detail (text, fabric texture), or any doubt — bitrate is the cheapest quality you'll ever buy and the last place to economize. Use 2-pass VBR for final deliveries (the encoder studies the whole piece, then spends its budget on the hard parts — worth the doubled render time; skip it for quick review copies).

H.6 Captions & subtitles — burned-in vs sidecar

Captions are the largest single accessibility gain you can deliver, and the difference between a social video that works sound-off and one that gets scrolled past. They are a deliverable, not an afterthought. First the vocabulary, which matters on delivery:

The decision that shapes your export is how the text attaches to the picture:

.srt (SubRip) is the near-universal sidecar format — a number, a timecode range, the line of text, a blank line, repeat. .vtt is its web cousin. Both are trivially simple, which is why they travel everywhere.

Why captions matter, in one place: roughly one in five viewers watches with the sound off; deaf and hard-of-hearing viewers cannot follow the piece at all without them; captions boost comprehension for non-native speakers and in noisy rooms; and platforms surface captioned video more. Auto-generated captions are a starting point, never a finished product — they mangle names, punctuation, and anything noisy. Read and fix them by hand every time; uncorrected auto-captions tell a deaf viewer you didn't think they were worth five minutes.

H.7 Loudness targets — master to the destination

Set the whole program's integrated (whole-program) loudness in LUFS, guard the true peak below the ceiling, and master to the target, not past it — every streaming platform normalizes loudness, so over-limiting to be "loud" just gets turned down and leaves you dynamically flat for nothing (Chapter 33, §33.6). dBFS/dBTP measures the instantaneous peak (clipping); LUFS/LKFS measures perceived loudness over time.

⚠️ Loudness targets are current, revisable specs — confirm your destination's before delivery (→ Chapter 33). The principle is stable even when a number shifts: measure integrated loudness, master to the destination's target, never cross the peak ceiling.

H.8 The delivery checklist — run it every time

The errors that ruin deliveries are almost never exotic; they are dumb, small, and preventable (a frame-rate mismatch, a leftover in/out range, a too-quiet mix, missing captions, a black frame at the tail). A checklist catches all of them. Screenshot this (full version: Chapter 36, FIGURE 36.6).

The single most-skipped, most-important line: watch the exported file, all the way through, in a plain player — not your timeline. The timeline in your memory is not the file on their screen. QC the file. Every time.

The one sentence: deliver H.264 in .mp4, matched to the timeline, at a generous bitrate, mastered to your destination's LUFS target, captioned for the way it will be watched; keep a ProRes .mov master you derive every version from; treat every number here as typical, at the time of writing and confirm the current spec at the source; then watch the file through, on a phone and a big screen, before anyone else does — because the export is the last place a great edit can die.