Chapter 36: Export, Delivery, and Distribution

Overview

Picture the last hour of a project you have poured a month into. The cut is locked. The color is corrected and graded — the warm café look you have been building since Chapter 1 finally sits on the timeline exactly right. The mix is clean, leveled, and mastered to the streaming loudness target you set in Chapter 33. Titles are spelled correctly. It is, on your monitor, the best thing you have ever made. There is one step left: get the file out of the software and into the world. So you open the export dialog, glance at whatever settings happen to be in it from the last job, click the button, wait for the render bar to crawl to the end, and upload.

And it comes back wrong. The smooth graded wall behind your subject has broken into ugly stepped bands it never had on your timeline. The image looks soft, like someone smeared a thumb across your sharp footage. The audio you so carefully balanced is either painfully quiet or the platform has yanked it down and it sounds crushed. Half the frame is cut off on a phone. There are no captions, so a fifth of your audience watches four seconds of a silent, contextless clip and scrolls on. The edit was perfect. The delivery destroyed it — in the ninety seconds it took to click through a dialog you did not understand.

This is the chapter that makes sure that never happens to you. Here is the whole idea, and it is worth carrying like a warning label: the export is the very last place you can ruin a great edit, and it is where more good work dies than almost anywhere else, because it is the one step people do carelessly. Every earlier chapter was about making the video good. This one is about getting it out at full quality, to the right place, in the right shape, so that all that work survives the trip. It is not glamorous. It is a checklist and a set of matching decisions. But a producer who cannot deliver is not a producer — they are someone with a hard drive full of things nobody ever saw correctly.

The good news is that delivery is not mysterious. It is a spec-matching craft: every destination — YouTube, Instagram, a broadcaster, a paying client — has a specification, a recipe of technical requirements, and your job is to hand it a file that matches. Match the recipe and the platform is your friend. Ignore it and the platform mangles your work on the way in and you never even find out why. Once you understand the handful of settings in the export dialog and where to find each platform's recipe, delivering correctly takes minutes and becomes automatic.

We build directly on Chapter 3. There, you learned what a video file is — the codec, the container, the bitrate — from the capture end: which codec your camera recorded the world into. This chapter turns that same knowledge around to face the other direction: which codec you encode your finished piece out into, and at what bitrate, in what container, for whom. Same vocabulary, opposite end of the pipe. If Chapter 3 was "what does the camera keep?", this chapter is "what do you send, and how do you keep it from breaking?"

In this chapter you will learn to:

• Read an export dialog field by field — container, codec, resolution, frame rate, bitrate, audio — and know what each one does to the file.
• Choose a delivery codec and a delivery bitrate for a destination, and pick the right wrapper (container) so the file actually plays where it is going.
• Match a piece to a platform delivery spec for YouTube, a vertical social cut, broadcast, and a client — and understand why every number in this chapter is written in pencil, not ink.
• Export and archive a high-quality master, then make every platform deliverable from it — never by re-compressing an already-compressed file.
• Add captions and subtitles on export, choosing between burned-in and sidecar, and deliver work that is usable with the sound off and by viewers who are deaf or hard of hearing.
• Run a delivery checklist that catches the frame-rate mismatch, the wrong loudness, the missing captions, and the black frame at the end — before anyone else sees them.

Learning Paths

Delivery is the one skill every reader needs, but the details you must sweat differ by where your work goes. Read for your destination:

• 📱 Phone-first: §36.1 (the dialog) and §36.3 (the vertical/social spec) are your sections. Your phone and your editor make most codec choices for you — what you must get right is exporting at the highest quality your app offers, matching 9:16, and burning in captions so a sound-off viewer stays. §36.5 matters more for you than for anyone.
• 🎥 Creator: §36.3 (platform specs) and §36.4 (masters) are the difference between a channel that looks "produced" and one that looks compressed. Learn why you upload a file far bigger than the platform will keep, and why you never delete your master.
• 💼 Pro-track: all of it, cold. Clients and broadcasters hand you a delivery spec and reject files that miss it. §36.2 (codecs/bitrates), §36.3 (broadcast and client), and §36.6 (the checklist and QC) are how you keep the account. The 🔬 The Tech boxes are worth your time.
• 🎓 Student: read straight through and do the Production Checkpoint, which delivers all three of your projects. This is where the whole book's spine finally ships. §36.4 (the master/deliverable discipline) is a habit that will save you for the rest of your career.

36.1 The export dialog demystified

Everything in post-production has been leading to one file. Let us name the act that produces it. To export — the same operation your software may call render, deliver, encode, or share — is to have the editor read through your finished timeline and write out a single new, self-contained video file: a fresh clip that bakes together every edit, every color node, every title, and the final mix into one flat piece of video that will play anywhere, with none of your project's original clips or software required. The word render emphasizes the work involved — the computer is building each frame of the new file from scratch, one at a time, which is why a long or effects-heavy piece takes real time to export. The word export emphasizes the result — a file leaving your project to go out into the world. They are the same button. When we say "export your piece," we mean: turn your editable timeline into one finished video file.

Understand first why this is even a separate step, because it explains everything that follows. Your timeline is not a video. It is a set of instructions — "play this clip from here to here, with this color correction, over this audio, then dissolve to that one." Those instructions only mean anything inside your specific software, pointing at your specific media files. You cannot email a timeline; you cannot upload one. Export is the act of performing all those instructions and recording the performance as a real, standalone video. And exactly like a live performance, the quality of the recording depends entirely on the settings you choose when you hit record — which is what the export dialog is for.

Open that dialog in any editor and, under whatever names and layout, you will find the same short list of decisions. Learn the fields, not the buttons, and you can export from any software on earth.

FIGURE 36.1 — The export dialog, demystified (a generic render dialog, field by field)

  ┌─ EXPORT / RENDER SETTINGS ─────────────────────────────────────┐
  │ Filename   cafe-scene_MASTER_v04                               │ ← name it to find it later (Ch.37)
  │ Location   /Project3/exports/                                  │
  │                                                               │
  │ FORMAT (container / wrapper) ▸  MP4     [ .mp4  .mov  .mxf ]   │ ← the "box" the file ships in
  │ CODEC                        ▸  H.264   [ H.265 ProRes DNxHR ] │ ← how the picture is packed (§36.2)
  │                                                               │
  │ RESOLUTION   ▸ 1920 x 1080     ( MATCH the timeline )          │ ← don't up/down-scale by accident
  │ FRAME RATE   ▸ 24 fps          ( MATCH the timeline )          │ ← a mismatch here = judder/stutter
  │ QUALITY      ▸ ( ) Restrict to bitrate  [  20  ] Mb/s          │ ← the DELIVERY BITRATE (§36.2)
  │              ▸ (•) Constant quality     [ High / Automatic ]   │
  │                                                               │
  │ AUDIO   codec ▸ AAC    sample rate ▸ 48 kHz    ▸ 320 kb/s      │ ← 48 kHz, loud enough, stereo
  │         channels ▸ Stereo                                     │
  │                                                               │
  │ RANGE   ▸ (•) Entire timeline    ( ) In/Out range only         │ ← render the WHOLE piece
  │ CAPTIONS ▸ ( ) Burn in    (•) Export as sidecar .srt           │ ← §36.5
  │ ADVANCED ▸ 2-pass VBR • keyframe ~1s • encoding profile: Main  │ ← §36.2 Tech
  └────────────────────────────────────────────────────────────────┘
   Every NLE has these same fields under different names. DaVinci Resolve — this book's free
   reference editor — gathers them on a dedicated "Deliver" page with a render queue; other
   editors put them in a "Media > Export" or "Share" dialog. See Appendix E for the translations.

Walk the fields in the order that matters. Format, sometimes called the container or wrapper, is the type of file you are making — .mp4, .mov, and so on. Codec is how the picture inside is compressed — H.264, H.265, ProRes. These two are the heart of the decision and get their own section next (§36.2); for now, just notice they are two separate choices, exactly the box-and-contents distinction you learned in Chapter 3.

Resolution and frame rate carry a single, enormous rule that catches beginners constantly: match your timeline, and change them only on purpose. If you cut a 1080p, 24 fps project, you export 1080p, 24 fps. The instant these fields disagree with your timeline, the software has to convert — scaling every frame up or down (which softens the image) or, worse, adding or dropping frames to change the rate (which makes motion stutter and judder). A huge fraction of "why does my export look worse than my timeline?" is a resolution or frame-rate mismatch introduced by a leftover preset from a different job. We will make catching this the first line of the delivery checklist.

Quality is where you set how hard the file is compressed on the way out — the delivery bitrate — and it usually appears as one of two modes: restrict to a bitrate (you name a number of Mb/s), or constant quality (you name a quality level and let the encoder spend whatever bitrate that takes). Section 36.2 is entirely about choosing here.

Audio is a field beginners skip and regret. Set it to a healthy codec (AAC for delivery, or uncompressed PCM for a master), a 48 kHz sample rate (the video standard — matching what you recorded and mixed), a generous bitrate (256–320 kb/s for AAC so your careful mix is not re-crushed), and the right channel layout (usually stereo). This is where a beautiful mix gets quietly degraded by a stingy default — do not let it.

Range decides how much of the timeline you render: the entire thing, or just a marked in-to-out section. The classic disaster is leaving an in/out range set from when you were reviewing one shot, and exporting fifteen seconds of a five-minute film. Confirm "entire timeline" every time unless you mean to export a section.

⚠️ Common Mistake: clicking through the dialog with last job's settings. The single most common way to ruin an export is to not look at the dialog at all — to accept whatever was in it from the last thing you rendered. That is how a 24 fps film gets exported at 30 fps (hello, judder), a 4K piece gets squashed to 720p, a vertical cut gets letterboxed inside a horizontal frame, or a two-minute video renders out as the eight-second section you had marked. The dialog is not a formality you click past; it is the set of decisions that determine whether your month of work arrives intact. Read every field, every time. It takes twenty seconds and it is the cheapest insurance in this book.

🎒 Gear Note: you do not need a fast computer to export well — only to export fast. Rendering is the most computationally heavy thing your editor does, so a modest laptop will take longer — sometimes much longer — to grind out a file, especially with a heavy grade or effects. That is a time cost, not a quality cost: a slow machine produces the identical file, just later. Two practical principles, gear-agnostic. First, if exports are painfully slow, many editors can use your computer's hardware encoder (a dedicated chip for H.264/H.265) to speed things up dramatically — a menu choice, not a purchase. Second, render overnight if you must; a long render is a reason to plan your delivery day, not a reason to buy a computer. Phone editors export right on the device — the same rule applies: pick the highest-quality setting and let it take the time it takes.

🔄 Check Your Eye. 1. In one sentence, what does "export" (or "render") actually do to your timeline? 2. Why does exporting at a different frame rate than your timeline damage the video? 3. You exported a five-minute film and got a fifteen-second clip. Which field did you get wrong?

Check yourself

1. It performs every instruction in your timeline — edits, color, titles, mix — and records the result as one new, self-contained video file that plays without your software or original clips.
2. The software must add or drop frames to change the rate, which makes motion stutter and judder; matching the timeline's frame rate avoids the conversion entirely.
3. The Range field — an in/out range was still set from reviewing a section; you needed "entire timeline."

36.2 Delivery codecs and bitrates: H.264/H.265, ProRes, and how hard to compress

Now the two decisions at the heart of the dialog: which codec you encode into, and how much data you let it use. This is Chapter 3's material, turned around to face outward.

In Chapter 3 you met codecs as families. There were the small delivery codecs — H.264 (AVC) and H.265 (HEVC) — that squeeze video tiny for cameras and the web, and the big editing codecs — Apple ProRes and Avid DNxHR — that stay large but cut smoothly. That was the story from the capture end: which family your camera recorded from the world. Now we stand at the other end of the pipe, and the same word turns to face the opposite way. A delivery codec is the codec you encode your finished export into for wherever it is going — the compression scheme applied on the way out, chosen to fit the destination rather than the camera. And the choice splits along the exact same seam you already know.

For anything headed to a viewer — YouTube, social, a link you send a client, a file that has to play on any phone or laptop on earth — your delivery codec is almost always H.264, occasionally H.265. This is not a compromise; it is correct. Delivery codecs exist to make a small, universal file, and "small and universal" is precisely what a finished video for the internet needs to be. H.264 is the closest thing video has to a universal language: essentially every device, browser, and platform made in the last decade plays it without a second thought. H.265 encodes the same quality in roughly half the data — genuinely useful for 4K, where files get large — but it is heavier for a viewer's device to decode and slightly less universally supported, so reach for it when file size is a real problem and fall back to H.264 when you want zero compatibility risk.

For a master — the pristine copy you keep and derive everything else from (§36.4) — you swap families entirely and encode into an editing codec: ProRes (usually ProRes 422 HQ) or DNxHR (usually HQX). These make a large file, and that is the point: a master should throw away as little as possible, because every deliverable will be born from it.

🔗 Connection. If the delivery-codec-versus-editing-codec split feels familiar, it should — it is the "small-and-hard-to-edit versus large-and-easy-to-edit" trade from Chapter 3, §3.1, seen from the delivery side. There, the trade governed how your edit felt. Here, it governs what you ship: an editing codec for the master you keep, a delivery codec for the copies you send. Same physics, opposite ends of the project.

The wrapper: which container to ship in

The codec's partner is the wrapper, the delivery-side name for the container you learned in Chapter 3 — the file type, named by its extension, that packages your encoded video, audio, and metadata into one shippable object. On delivery this choice is mostly about compatibility, and it follows the codec almost automatically:

• .mp4 is the universal delivery wrapper. It holds H.264 or H.265, and it plays everywhere — every platform, every phone, every browser. When in doubt, deliver an .mp4. It is the safe default for YouTube, social, and most clients.
• .mov is the professional and Apple-ecosystem wrapper, and it is the standard home for ProRes masters. Many clients and all broadcasters expect masters as .mov. It also holds H.264, but for a plain delivery file .mp4 travels more smoothly.
• .mxf is a broadcast wrapper you will meet only if a broadcaster's delivery spec demands it (§36.3). If they ask for it, you will be given exact instructions; if they do not, you will never touch it.

The rule of thumb writes itself: .mp4 with H.264 for delivery to people and platforms; .mov with ProRes for the master you keep. That single sentence covers the overwhelming majority of everything you will ever export.

Delivery bitrate: how hard to compress on the way out

Choosing the codec decides how the file is compressed; the delivery bitrate decides how hard — the amount of data, in megabits per second (Mb/s), the encoder is allowed to spend on each second of your finished video. It is the exact mirror of Chapter 3's capture bitrate. There, a higher number meant the camera kept more of the world. Here, a higher number means the export throws away less of your finished, graded, mixed picture. Starve it and the compression artifacts you learned to name in Chapter 3 — banding in the graded gradients, macroblocking in the shadows, smearing on motion — reappear in the delivered file even though your timeline was clean.

You set the bitrate in one of two modes, and it is worth knowing both:

• Restrict to a bitrate (target a specific Mb/s) — you name the number. Use this when a platform or client tells you a bitrate, or when you must hit a specific file size.
• Constant quality (name a quality level, let the bitrate float) — you tell the encoder "keep it this good" and it spends whatever bitrate each moment needs, more on the hard parts and less on the easy ones. This is often the smartest choice for your own uploads, because it spends data where the image actually needs it.

How much is enough? The honest, permanent answer is: match or comfortably exceed the recommended upload bitrate for wherever it is going, and when you have the storage, err high. Delivery bitrate is cheap quality — the last place you should economize. A rough, hedge-everything sense of scale, to be verified against Appendix H and the platform's current guidance:

FIGURE 36.2 — A delivery preset, read out (a typical "YouTube 1080p" export — verify vs Appendix H)

  ┌─ PRESET: "Web delivery — 1080p H.264" ─────────────────────────┐
  │ FORMAT / WRAPPER   .mp4                                        │
  │ CODEC              H.264  (High profile)                       │
  │ RESOLUTION         1920 x 1080     ← matches a 1080p timeline  │
  │ FRAME RATE         24 fps          ← matches the timeline      │
  │ BITRATE            ~10–20 Mb/s, 2-pass VBR  (or "constant      │
  │                    quality: high")  ← the platform re-encodes, │
  │                    so give it a CLEAN, generous file to chew on│
  │ AUDIO              AAC, 48 kHz, stereo, 320 kb/s               │
  │ LOUDNESS           mix already mastered to ~-14 LUFS (Ch.33)   │
  │ CAPTIONS           sidecar .srt uploaded with the file (§36.5) │
  └────────────────────────────────────────────────────────────────┘
   4K/UHD (3840x2160) wants SEVERAL TIMES this bitrate — big files are correct here.
   These numbers are TYPICAL and change often. Never trust a bitrate from memory for a paid
   job: pull the current figure from Appendix H (Delivery & Codec Reference) or the platform.

💡 Why It Works: upload more than the platform will keep. Here is the counter-intuitive rule that separates crisp channels from mushy ones. Every big platform re-encodes your upload — it takes your file and compresses it again into its own formats and bitrates for streaming. You cannot stop this. So why upload a high-bitrate file if the platform is just going to squash it? Because a re-encode is only as good as the file it starts from. Compression is lossy (Chapter 3): every pass throws detail away and cannot add it back. Hand the platform a clean, generous, high-bitrate file and its re-encode has plenty of quality to work from — the result looks sharp. Hand it a stingy, already-damaged file and its re-encode compresses your artifacts, stacking new damage on old, and the result looks terrible. You are not fighting the platform's re-encode; you are feeding it. Give it the best possible starting point and let it do its worst — the worst of a great source still looks good.

🔬 The Tech: CBR vs VBR, and why 2-pass helps. Two encoder options sit under the bitrate field. CBR (constant bitrate) spends the same data every second, whether the frame is a still wall or a chaotic crowd — simple, predictable file size, but wasteful (it over-spends on easy frames and under-spends on hard ones). VBR (variable bitrate) lets the data float — little on easy frames, lots on hard ones — for better quality at the same average size; it is what you usually want. VBR comes in 1-pass (the encoder guesses on the fly) and 2-pass (the encoder watches the whole video once to find the hard parts, then encodes on a second pass, spending its budget intelligently). Two-pass takes twice as long and produces a noticeably better file at a given size — worth it for a final delivery, skippable for a quick review copy. One more term you may see: the keyframe interval (or GOP length), which — recalling Chapter 3's interframe compression — sets how often the encoder writes a full frame. For delivery you generally leave it at the default (often about one keyframe per second, or matched to your frame rate); some streaming and broadcast specs require a specific value, in which case the spec tells you. Skip this box and your uploads will still be fine; read it and you will squeeze the last few percent of quality out of a fixed file size.

✂️ In the Edit. The export is where every earlier decision in the whole book comes due, and it is merciless about the ones you got wrong. Shoot 8-bit 4:2:0 and grade it hard (Chapter 3), and the delivery encode — a second lossy compression on top of the capture compression — will band those stretched gradients worse than your timeline ever showed. Build a timeline at the wrong frame rate and the export judders. Mix too quiet and the platform's loudness normalization (Chapter 33) yanks you around. None of these can be fixed in the export — the export only reveals them. This is "you shoot for the edit" (Chapter 1) followed all the way to its end: you shoot for the edit, you edit for the delivery, and the delivery is honest about the entire chain. The one mercy is that a clean chain delivers clean — do the earlier chapters right and this one is easy.

🔄 Check Your Eye. 1. What delivery codec and wrapper do you use for a video going to YouTube or a client link, and why that pair? 2. What is a delivery bitrate, and why upload a higher one than the platform will ultimately keep? 3. What does 2-pass VBR do that 1-pass doesn't, and when is it worth the extra time?

Check yourself

1. H.264 in an .mp4 wrapper — H.264 is the near-universal delivery codec that plays everywhere, and .mp4 is the universal container; together they are the safest "it will just play" delivery.
2. The delivery bitrate is how much data the encode spends per second of the finished video (Mb/s). You upload high because the platform re-encodes your file and can only work from the quality you give it — a clean, generous source survives the re-encode; a starved one compounds its damage.
3. Two-pass analyzes the whole video first, then spends its bitrate budget on the hard parts, giving better quality at a given file size; it is worth the doubled render time for a final delivery, not for a quick review copy.

36.3 Platform delivery specs: YouTube, socials, broadcast, and the client

You now know the fields and the codecs. The question that remains is the one that changes with every destination: what, exactly, does this place want? That recipe has a name. A platform delivery spec is the complete set of technical requirements a destination expects a finished file to meet — its resolution and frame rate, its codec and container, its bitrate, its loudness target, its aspect ratio, its caption format, and sometimes its maximum length or file size. It is the answer key for the export dialog. Chapter 23 introduced you to platform specs for social short-form; the delivery spec is that idea generalized to every destination you will ever ship to, and treated as the contract it really is.

Here is the single most important thing to understand about delivery specs, and the reason this chapter refuses to hand you a table of numbers to memorize: the numbers change, constantly, and without warning. Platforms revise their recommended bitrates, add new codecs, change their aspect ratios, and shift their loudness targets whenever they like. A spec you memorize today is a spec that is wrong next year. So the numbers below are written as typical values at the time of writing, purely to teach you the shape of each destination — and the one durable skill: for anything that matters, you look the current spec up. Appendix H (the Delivery & Codec Reference) collects these, and even it will tell you to confirm against the platform's own current help pages before a paid delivery. The skill is not knowing the number. The skill is knowing that a number exists, that it changes, and where to find today's.

FIGURE 36.3 — Platform delivery specs: the shape of four destinations (TYPICAL / at time of writing — verify against Appendix H)

Read the table across, not down, and four personalities emerge.

YouTube is the forgiving one. It accepts a huge range of resolutions and frame rates, it wants a standard H.264 .mp4 (increasingly H.265 or AV1 for 4K), and it re-encodes everything, so the rule from §36.2 governs: upload a clean, generous, high-bitrate file and let it do its thing. It normalizes loudness toward the streaming neighborhood you already mastered to in Chapter 33, so your -14 LUFS mix arrives about right. Captions can ride along as a sidecar file you upload or be typed on the platform — and you should always provide them rather than trust auto-captions alone (§36.5).

Vertical social — Reels, TikTok, Shorts — is the demanding, phone-shaped one, and Chapter 23 already taught you its frame: 9:16, 1080×1920, subject and text inside the safe zones so the interface does not cover them. Its personality on delivery is aggressive: heavy compression, aggressive loudness handling, and an audience watching on a phone with the sound off. That last fact drives the biggest delivery difference — on social you usually burn your captions in (§36.5), because a sidecar file the viewer must switch on is a file nobody switches on. If you are repurposing a horizontal piece to vertical, that reframing work is Chapter 23's §23.5; here we assume the vertical cut exists and we are shipping it.

Broadcast and professional OTT (television, streaming networks, festivals) is the strict one, and it operates by a completely different rulebook. You do not guess a broadcast spec — you are handed one, a document that dictates the exact resolution and frame rate (often unfamiliar ones — 1080i interlaced, 23.98 or 25 fps, specific for that territory), a specific high-quality codec (frequently ProRes in a .mov, or a named codec in an .mxf), a precise loudness standard that is not the streaming -14 (broadcast runs quieter and tighter — around -23 LUFS under the European EBU R128 standard, or -24 LKFS under the North American ATSC A/85 standard, with a strict true-peak ceiling), a required caption format delivered as a separate file, and often technical furniture like bars, tone, a slate, and a specific amount of black at the head and tail. Miss any line and the file bounces. The skill here is not memorization; it is reading the delivery document exactly and matching it line by line, and asking when unsure. We flag it so you are not blindsided the first time a broadcaster sends you a two-page spec.

The client file is the ambiguous one, and its defining feature is that the spec is often missing. A client says "send me the final video" and names nothing. Your move is twofold: ask ("where will this live — your website, social, a trade-show screen, broadcast? and do you need the editable master?"), and, absent an answer, deliver a safe, universal high-quality file — 1080p (or 4K if you shot and finished it there), H.264, .mp4, at a generous bitrate, mastered to about -14 LUFS — which plays anywhere and embarrasses no one. And whatever you deliver to a client, you keep the master (§36.4), because "can you also send it in a different format / for TV / for the big screen?" is a question every good client eventually asks.

⚙️ Settings Box: four starting-point delivery recipes (typical — verify current specs against Appendix H).

Situation	Wrapper / codec	Resolution / fps	Bitrate	Loudness	Captions
YouTube, 1080p	.mp4 / H.264	1920×1080 / match timeline	~10–20 Mb/s or "high quality", 2-pass	~-14 LUFS	sidecar .srt
YouTube, 4K	.mp4 / H.264 or H.265	3840×2160 / match	several× the 1080p figure	~-14 LUFS	sidecar .srt
Vertical social	.mp4 / H.264	1080×1920 (9:16)	moderate, generous	~-14 LUFS	burned-in
Client master	.mov / ProRes 422 HQ	match timeline exactly	(codec-determined, high)	~-14 LUFS	clean master + separate .srt

Starting points, not laws. A broadcast deliverable is deliberately absent here — that one you take only from the broadcaster's own spec document, never from a table like this.

🎬 On Set: deliver a piece to two homes. Take any finished (or near-finished) short piece you have — one of the four recurring setups is ideal: your talking-head, a walk-and-talk, a product clip, or an event highlight. Export it twice: once as a 16:9 YouTube deliverable (H.264 .mp4, matched resolution and frame rate, generous bitrate, a sidecar .srt) and once as a 9:16 vertical social deliverable (1080×1920, burned-in captions, subject inside the safe zone). Constraint: do not re-use one export's settings for the other — build each to its own spec. Self-review: play both on an actual phone. Does the vertical one keep your subject and captions clear of where the interface sits? Does the horizontal one look as sharp as your timeline? If either looks worse than what you cut, which field in the dialog explains it? This is the core delivery skill — one source, two specs, two correct files — and it is exactly what the Production Checkpoint scales up to all three projects.

🔄 Check Your Eye. 1. What is a platform delivery spec, and why does this chapter refuse to make you memorize the numbers? 2. Why do you usually burn captions into a vertical social video but deliver them as a separate file to YouTube or broadcast? 3. A client says only "send me the final." What two things should you do?

Check yourself

1. It is the full set of technical requirements a destination expects — resolution, fps, codec, container, bitrate, loudness, aspect, captions. The numbers change constantly, so the durable skill is knowing a spec exists and where to look up today's (Appendix H / the platform), not memorizing a figure that will be wrong next year.
2. Social is watched sound-off on a phone and a sidecar caption the viewer must enable is one nobody enables, so you burn them in; YouTube and broadcast support and expect a sidecar file, which is toggleable, translatable, searchable, and accessible to screen readers.
3. Ask where it will live and whether they need the master; and, absent an answer, deliver a safe universal high-quality file (1080p/4K H.264 .mp4, generous bitrate, ~-14 LUFS) — while keeping your own master.

36.4 Masters versus deliverables: keep a high-quality master

We have quietly used the word "master" several times. Now we make it a discipline, because it is the single habit that most separates a professional delivery workflow from an amateur one — and it is almost free.

Here is the problem it solves. Compression is lossy and permanent (Chapter 3): every time you encode video into a delivery codec, you throw detail away for good. So imagine the amateur workflow. You finish your edit, export a compressed H.264 for YouTube, and — needing an Instagram version — you take that already-compressed YouTube file, import it, and export it again to 9:16. You have now compressed a compression: stacked a second round of lossy encoding on top of the first, so the vertical cut is visibly worse than the horizontal one. Then the client asks for a version for a lobby screen, and you compress the compression of the compression. Each generation is a photocopy of a photocopy. This is called generation loss, and it is entirely avoidable.

The professional workflow avoids it with one rule: make a master, keep it, and derive every deliverable from it — never from another deliverable.

A master is the single highest-quality, self-contained export of your finished piece — full resolution, full frame rate, the least compression you can afford — that you archive and treat as the authoritative copy of the work. It is typically encoded in an editing codec (ProRes 422 HQ or DNxHR HQX) in a .mov, precisely because those keep almost everything. It is large — hundreds of Mb/s, an order of magnitude fatter than a delivery file — and that size is the whole point: it is the pristine negative from which you print every copy. A master is kept clean: full quality, and — importantly — usually without burned-in captions, so it can serve any future purpose (a different platform, a translated caption set, a re-edit).

A deliverable — the term you met back in Chapter 1 — is here a compressed, platform-matched copy made for a specific destination: the H.264 .mp4 for YouTube, the 9:16 for social, the file for the client. Deliverables are meant to be re-made; the master is meant to be kept.

FIGURE 36.4 — One master, many deliverables (derive from the master, never from a deliverable)

                         ┌─────────────────────────────┐
     LOCKED TIMELINE ──► │   THE MASTER                │  ProRes 422 HQ / DNxHR HQX, .mov
     (color, mix,        │   full res • full fps       │  full quality • no burned-in captions
      graphics, all      │   ~hundreds of Mb/s         │  → ARCHIVE THIS (Ch.37): it is the
      final)             │   the authoritative copy    │    negative you print every copy from
                         └──────────────┬──────────────┘
                                        │  (re-render from the TIMELINE, or transcode from the MASTER —
                                        │   NEVER export one deliverable from another)
              ┌─────────────────────────┼─────────────────────────┐
              ▼                         ▼                         ▼
     ┌────────────────┐        ┌────────────────┐        ┌────────────────┐
     │ YouTube 16:9   │        │ Social 9:16    │        │ Client .mp4    │
     │ H.264 .mp4     │        │ H.264, burned- │        │ 1080p H.264    │
     │ + sidecar .srt │        │ in captions    │        │ (+ master if   │
     │                │        │ safe zones     │        │  they ask)     │
     └────────────────┘        └────────────────┘        └────────────────┘
       Each deliverable is ONE generation from the source. None is a copy of a copy.

Two honest, practical notes keep this from becoming dogma. First, where you derive deliverables from is a small judgment call. The theoretically best quality comes from re-rendering each deliverable straight from your timeline — every deliverable is then a first-generation export, and you can also re-do the color for a different color space or reframe for vertical properly along the way. The convenient alternative is to transcode from the master — fast, and since the master is nearly lossless, the extra generation is almost invisible. Both are fine. What is not fine is the amateur move: exporting one lossy deliverable from another lossy deliverable. Go back to the master (or the timeline); never photocopy a photocopy.

Second, if storage is genuinely tight — a phone-first reader, a full drive — a "master" can be a high-bitrate H.264 rather than a giant ProRes. It is not as pristine, but a generous H.264 master is still far better to derive from than a stingy delivery file, and it beats having no master at all. The principle survives the budget: keep the best single copy you can afford, and derive from it.

🚪 Threshold Concept: deliver from a master, not a timeline you might lose. The amateur thinks the timeline is the finished work and the exports are throwaways. The professional thinks the master is the finished work and the timeline is scaffolding. This inversion matters because timelines rot — the software updates, a plugin breaks, a media drive dies, and two years later your beautifully cut project will not re-open, or re-opens with missing media and shifted color. A self-contained master file has none of those dependencies: it is one flat video that will play in fifty years. So the moment a piece is truly done, your first act is to render a master and archive it (Chapter 37). Everything else — every platform version, every re-cut request, every "can you send it again?" — is served from that master. Once you internalize this, you stop treating export as the end of a project and start treating it as the creation of the project's permanent, authoritative form.

🔗 Connection. The master is not just made — it is kept, and keeping it is the subject of the very next chapter. Chapter 37 covers file naming, folder structure, the 3-2-1 backup rule, and archiving a finished project so you could reopen it in a year. Your master file is the single most important thing that backup protects: lose your project and your media and you have lost the ability to re-edit, but keep the master and you have never lost the film. Render the master here; archive it there.

🔄 Check Your Eye. 1. What is generation loss, and what everyday delivery habit causes it? 2. How does a master differ from a deliverable — in codec, size, and purpose? 3. Why should a master usually not have captions burned into it?

Check yourself

1. Generation loss is the compounding quality damage from compressing already-compressed video; it is caused by exporting one lossy deliverable from another (e.g., making the Instagram cut out of the finished YouTube file) instead of from the master or timeline.
2. A master is the highest-quality self-contained copy — an editing codec (ProRes/DNxHR), large (hundreds of Mb/s), kept and archived as the authoritative version; a deliverable is a compressed, platform-specific copy (H.264, small) meant to be re-made from the master.
3. So it can serve any future purpose — a different platform, a translated or corrected caption set, a re-edit — without the wrong open captions baked permanently into the picture; captions belong on the deliverables (burned-in) or as sidecar files.

36.5 Captions, subtitles, and accessibility on export

A video that part of your audience cannot follow is not finished — it is finished for some people. Chapter 1 planted this; here, at the moment the file goes out, is where you make good on it. Captions are the largest single accessibility gain you can deliver, they are the difference between a social video that works sound-off and one that gets scrolled past, and they are a choice you make right here in the export. So we treat them properly.

Start with the vocabulary, because "captions" and "subtitles" are used loosely and the distinctions matter on delivery. Captions are a same-language text rendering of a video's audio, intended primarily for viewers who are deaf or hard of hearing — and true captions include not just dialogue but the meaningful sounds ([phone rings], [tense music], speaker changes). The fuller form is often labeled SDH (Subtitles for the Deaf and Hard-of-hearing). Subtitles, strictly, are a translation of the dialogue into another language for viewers who can hear but do not speak the language, and typically omit the sound cues. In everyday delivery you will mostly make same-language captions; know that SDH is the accessible, sound-inclusive version and that translation subtitles are a separate, additional deliverable.

The decision that actually shapes your export is how the captions attach to the video, and there are two ways.

FIGURE 36.5 — Two ways to attach captions: burned-in (open) vs sidecar (closed)

  BURNED-IN (OPEN) captions                 SIDECAR (CLOSED) captions
  ───────────────────────                   ─────────────────────────
  Text is rendered into the PIXELS of       Text lives in a SEPARATE file (.srt, .vtt)
  the video — part of the picture itself.   with timecodes; the player/platform draws
                                            it over the video on demand.
   ┌───────────────────────┐                 ┌───────────────────────┐   + example.srt:
   │                       │                 │                       │     1
   │      [ picture ]      │                 │      [ picture ]      │     00:00:02,000 -->
   │                       │                 │                       │     00:00:04,500
   │  ▓▓ "burned into it" ▓│                 │   (clean — no text     │     So here's the thing.
   │     — always visible   │                 │    baked in)           │
   └───────────────────────┘                 └───────────────────────┘
   ✅ always visible, sound-off safe          ✅ viewer toggles on/off; multi-language
   ✅ you fully control font/size/placement    ✅ searchable, screen-reader friendly, editable
   ✅ can't be turned off or stripped          ✅ keeps the picture clean; fixable after upload
   ❌ can't be turned off; one language only    ❌ needs a player/platform that supports it
   ❌ permanent — wrong caption = re-export      ❌ a file nobody enables is a file nobody reads
   → USE FOR: vertical social, sound-off feeds  → USE FOR: YouTube, broadcast, client, archive

Burned-in (also called open) captions are drawn permanently into the video's pixels — they are the picture, always on, impossible to switch off. Their strength is guarantee: they will be seen, they look exactly as you styled them, and no player or setting can hide them. Their weakness is their permanence and inflexibility: one language, no toggle, and if you typo a word you must re-export. Burn captions in when you need the guarantee — vertical social video watched with the sound off is the classic case, where a caption the viewer must enable is a caption that never appears.

Sidecar (also called closed) captions live in a small separate text file — most commonly an .srt (SubRip) or .vtt — that stores each line of text with its start and end timecode. The video stays clean; the player or platform overlays the text on demand, and the viewer can turn it on or off. Sidecars are flexible in every way burned-in captions are not: toggleable, translatable (ship several files for several languages), searchable by platforms and search engines, readable by assistive technology, and correctable after the fact without re-rendering a frame. Use a sidecar for YouTube, broadcast, most client work, and always for your archived master. The .srt format is refreshingly simple — a number, a timecode range, the line of text, a blank line, repeat — which is why it is universal.

How do you actually make them at export time? Three routes, all of which end at the dialog:

1. Type them on a caption/subtitle track in your editor, then, in the export, choose to either burn them into the picture or export them as a sidecar .srt (many editors, DaVinci Resolve included, put both options right in the export/Deliver settings — see Appendix E for where each NLE hides them).
2. Auto-generate, then correct. Your editor or the platform can transcribe speech to captions automatically. This is a starting point, never a finished product — auto-captions mangle names, punctuation, and anything noisy. Always read and fix them. Uncorrected auto-captions are worse than a sincere apology; they tell a deaf viewer you did not think they were worth five minutes.
3. Upload the sidecar to the platform. For YouTube and similar, you upload the .mp4 and the .srt separately; the platform marries them.

Captions are the headline, but accessibility on delivery is broader, and the export is where several of these become final:

• Readable on-screen text. Any title, lower third, or caption must be legible: high contrast against its background, large enough to read on a phone, and held on screen long enough to read at a comfortable pace. The graded gradients that banding can wreck (Chapter 3) are often exactly the backgrounds text sits on — a clean export keeps them legible.
• Do not let color alone carry meaning. A meaningful share of viewers are color-blind; if red-versus-green (or any color pair) is the only thing distinguishing two things on screen, some viewers get nothing. Add a label, a shape, a position.
• Photosensitivity-safe motion. Rapid, high-contrast flashing can trigger seizures. Avoid strobing and harsh flashes (a widely used guideline is no more than three flashes in any one second); if your piece has an unavoidable flash, a content warning at the head is the responsible minimum. This is a delivery-time gate: check it before you ship.
• Audio description — a narrated track describing key visual action for blind and low-vision viewers — is the picture's counterpart to captions. Full audio description is often a separate deliverable, but the habit of writing so the audio can stand alone (not relying on unspoken on-screen text to carry essential information) is free and starts now.

♿ Accessibility & Inclusion: captions are not optional and not an afterthought — they are a deliverable. Treat every finished piece as needing captions the way it needs audio. The reasons stack: 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. The professional standard is simple — caption everything you deliver, and correct the captions by hand. Pick the attachment method by destination (burned-in for sound-off social, sidecar for everywhere else), keep your master clean so a corrected or translated caption set can be added later, and never ship uncorrected auto-captions to a real audience. Accessibility done at delivery is cheap, fast, and the mark of someone who respects everyone they are talking to. Done never, it quietly excludes people who wanted to watch.

🔄 Check Your Eye. 1. What is the difference between burned-in and sidecar captions, and which do you use for a vertical social video? 2. What is an .srt, and name two things a sidecar caption can do that a burned-in one cannot. 3. Why are uncorrected auto-generated captions not acceptable as a final deliverable?

Check yourself

1. Burned-in (open) captions are rendered permanently into the video's pixels — always visible, one language, not toggleable; sidecar (closed) captions live in a separate timecoded file the player overlays on demand. For sound-off vertical social you burn them in, so they are guaranteed to appear.
2. An .srt is a simple sidecar caption file storing each line of text with its start/end timecode. A sidecar can be toggled on/off, offered in multiple languages, searched by platforms, read by assistive tech, and corrected after upload — none of which burned-in text allows.
3. Auto-captions reliably mangle names, punctuation, and anything spoken over noise; shipping them uncorrected gives deaf and hard-of-hearing viewers an inaccurate, sometimes nonsensical version of the audio — worse than doing captions properly, and a signal you did not take the audience seriously.

36.6 The delivery checklist

Every earlier section was a decision. This one is a ritual — the run-through you do every single time, before and after you export, because the errors that ruin deliveries are almost never exotic. They are dumb, small, and completely preventable: the wrong frame rate, a leftover in/out range, a mix that is too quiet, captions that never got attached, a black frame at the tail, the 4K master accidentally sent to the client who wanted a small file. A checklist catches all of them, which is why every field that cannot afford mistakes — aviation, surgery, broadcast — runs on one. Adopt this and delivery stops being the scary last step and becomes a calm, boring, reliable finish.

FIGURE 36.6 — The delivery checklist (run it every time; screenshot it)

  BEFORE YOU EXPORT — is the timeline actually done?
   □ Picture locked: no more edit changes (delivery is for a LOCKED cut)
   □ Color final: corrected + graded, checked on a calibrated-ish screen (Ch.31, 32)
   □ Audio final: mixed and MASTERED to the destination's loudness (~-14 LUFS streaming, Ch.33)
   □ Titles/lower thirds/captions: spell-checked, on long enough to read, inside safe areas
   □ Heads & tails clean: no black gaps mid-timeline, no accidental frames at the ends
   □ Full length present: audio and video run the whole piece (no track ending early)

  THE EXPORT SETTINGS — does the dialog match the destination? (§36.1–36.3)
   □ Container + codec right for the destination (.mp4/H.264 to ship; .mov/ProRes master)
   □ Resolution + frame rate MATCH the timeline (the #1 silent quality killer)
   □ Bitrate generous (constant-quality "high" or the platform's number, 2-pass for finals)
   □ Audio: 48 kHz, healthy bitrate, correct channels
   □ Range = ENTIRE timeline (not a leftover in/out)
   □ Captions handled: burned-in (social) or sidecar .srt (everywhere else)

  AFTER YOU EXPORT — QC the FILE, not the timeline (this is non-negotiable)
   □ Watch the exported file start to finish (it is a different thing than your timeline)
   □ Check it on a PHONE and on a big screen — does it hold up both places?
   □ Loudness sane, no clipping; captions display and are correct; nothing cut off by safe zones
   □ File plays on a machine WITHOUT your editing software (a clean player)
   □ File size sane for the destination (a 9 GB "social clip" is a mistake)

  BEFORE YOU SEND — the handoff
   □ Named clearly + versioned (project_deliverable_v03) so it survives (Ch.37)
   □ The RIGHT version and the RIGHT spec for THIS recipient
   □ Master rendered and ARCHIVED (Ch.37) before you move on
   □ Sidecar captions + any notes included; delivered by the method they expect

The most important line in that checklist, and the one beginners skip most, is watch the exported file, start to finish, in a plain player — not your timeline. Your timeline is not the deliverable; the exported file is, and the two can differ in ways only playback reveals: a render glitch, a codec the file wrongly assumed, captions that did not attach, audio that drifted, a frame rate that judders on a real screen. Ten minutes watching your own finished file is the last gate before an audience or a client watches it, and it is the gate that catches the truly embarrassing errors. Watch it on a phone and something bigger, because those two screens fail differently — the phone reveals safe-zone and legibility problems, the big screen reveals compression and color problems.

⚠️ Common Mistake: delivering the timeline's feeling instead of the file's reality. After weeks inside a project you know it is good — you have watched the timeline a hundred times — so you export and send without watching the actual file, trusting your memory of the cut. Then the client opens a file with a frame rate mismatch, or no captions, or a wrong-loudness mix, and your credibility takes the hit for a thirty-second oversight. The timeline in your memory is not the file on their screen. QC the file. Every time. The one habit of watching your own export all the way through, on the devices your audience uses, prevents the large majority of delivery disasters — and it is completely free.

🎬 On Set: build your own delivery checklist and use it live. Copy FIGURE 36.6 into a note (or print it) and run it, line by line, on your very next export — including the after-export QC. Constraint: actually check each box; do not eyeball it. Self-review: did any line catch something you would otherwise have shipped — a mismatched frame rate, a missing caption, a too-quiet mix, a leftover in/out range? Note which line saved you. That is the line that will save you again, and the reason professionals never deliver from memory. Keep the checklist; it is the last tool you touch on every project for the rest of your career.

🔄 Check Your Eye. 1. Why must you watch the exported file rather than trusting your memory of the timeline? 2. Name three things that belong on the "before you export" part of the checklist. 3. Why check a deliverable on both a phone and a large screen?

Check yourself

1. The exported file is the actual deliverable and can differ from the timeline in ways only playback reveals — render glitches, unattached captions, drifting audio, judder, wrong loudness — so QC-ing the file is the last gate before the audience sees exactly what you send.
2. Any three: picture locked; color final; audio mixed and mastered to the target loudness; captions/titles spell-checked and legible; clean heads and tails; full-length audio and video.
3. The two screens fail differently — a phone exposes safe-zone, legibility, and caption problems; a big screen exposes compression, banding, and color problems — so checking both catches more.

Production Checkpoint

Your task: deliver all three of your portfolio projects — a high-quality master plus the platform deliverables each one needs, every deliverable captioned — and, with that, lock and deliver Project 3. This is the checkpoint the entire book has been building toward. Project 1 (your 60-second talking-head) locked back in Chapter 15; Project 2 (your documentary short) locked in Chapter 30; Project 3 (your 5-minute branded piece) has been finished across Parts VII and VIII — corrected, graded, mixed, titled — and now it ships. When you finish this checkpoint, Project 3 is delivered, and all three of your videos exist as real, correct, shareable files.

Do this for each of the three projects, running the checklist (FIGURE 36.6) every time:

1. Render and archive a master. Export each finished project as a high-quality master — ProRes 422 HQ or DNxHR HQX in a .mov if your storage allows, or a high-bitrate H.264 if it does not — at the project's full resolution and frame rate, matched exactly to the timeline, with a clean picture (no burned-in captions on the master). Name it clearly and set it aside to archive in Chapter 37. This is the authoritative copy of the work.
2. Derive the platform deliverables each project needs — from the master or the timeline, never from another deliverable. At minimum: a 16:9 web deliverable (H.264 .mp4, generous bitrate, mastered to ~-14 LUFS) for YouTube or a client link; and a 9:16 vertical social deliverable (1080×1920, subject and text inside the safe zones per Chapter 23) for at least one project. If Project 3 has a specific client destination from its brief (Chapter 22), build the exact file that destination's spec calls for.
3. Caption every deliverable. Sidecar .srt for the web/client versions; burned-in captions for the vertical social versions. If you auto-generate, correct them by hand.
4. QC every file before you call it done. Watch each exported file start to finish, on a phone and a larger screen. Confirm the frame rate, the loudness, the captions, the aspect ratio, and that nothing is cut off or glitched. Fix and re-export anything that missed.

Why this matters: delivery is the step where a finished edit becomes a video other people can actually watch, correctly, wherever it lives — and it is the step most likely to silently undo all the work that came before it. By exporting a permanent master and deriving clean, spec-matched, captioned deliverables from it, you are doing exactly what a working professional does on every paid job, and you are proving the whole arc of this book: you took an idea, planned it, shot it, cut it, finished it, and delivered it to the world at full quality. Your three projects are now three real films. In Chapter 39 you will cut them into a reel — but first, in Chapter 37, you will make sure you never lose them.

Summary

A reference-grade recap of getting a finished piece out at full quality.

The export dialog, field by field:

Codecs and wrappers — the delivery-side trade (build on Ch.3):

Platform delivery specs — the shape (TYPICAL; verify against Appendix H):

Decision rules to carry:

• The export is the last place to ruin a great edit. Read every field of the dialog, every time.
• Match resolution and frame rate to the timeline. A silent mismatch is the #1 quality killer.
• H.264 .mp4 to deliver; ProRes .mov for the master. One sentence covers most of your career.
• Upload higher than the platform will keep — it re-encodes, and can only work from the quality you give it.
• Specs change: treat every number as "typical, at the time of writing," and look up the current one (Appendix H).
• Make a master, keep it, derive every deliverable from it — never export one lossy deliverable from another (generation loss).
• Caption everything, correct auto-captions by hand, and pick burned-in (social) vs sidecar (elsewhere) by destination.
• QC the exported file — watch it start to finish, on a phone and a big screen — before anyone else does.

Common mistakes → fixes:

This chapter's project step: deliver all three projects — a high-quality master plus captioned platform deliverables each — and, with that, lock and deliver Project 3.

Spaced Review

Bringing back Chapter 3 (the capture end of everything you just did in reverse) and Chapter 31 (the finish this delivery has to preserve). Answer from memory, then check.

1. Chapter 3 taught the codec-versus-container distinction from the capture side. State it again from the delivery side: when you export an .mp4 with H.264, which of those two is the codec and which is the container — and why can a .mov and an .mp4 both hold H.264?
2. Chapter 3 warned that compression is lossy and permanent, and that heavy grading of 8-bit 4:2:0 footage bands. Why does that same fragility come back to bite you again at the delivery encode, and what does it imply about the bitrate you export at?
3. Chapter 3's rule was "never format a card until its footage lives in two other places." What is the delivery-chapter cousin of that rule — the thing you render and protect the moment a piece is done?
4. Chapter 31 had you correct and match shots to a neutral, consistent baseline using scopes before any creative grade. Why must all of that color work be truly final before you export a master — what can the export not fix?

What's Next

You have delivered — your three projects are real, correct, captioned files, and Project 3 is done. But you now also have something dangerous: a master file, a project, and the media it depends on, all of which represent weeks of work and any of which a dead drive could erase in an instant. The professional habit that most separates people who have a career from people who had one is brutally simple: they never lose work. In Chapter 37 we build that habit into a system — a folder structure that scales, file names that survive, the 3-2-1 backup rule, and an archive you could reopen in a year — starting with the master you just rendered. You made the film. Now we make sure it, and everything behind it, is never lost.