Export delivery masters

What this is about

Delivery works in two layers. The mezzanine master is a high-quality intermediate in a codec built for editing, and everything that is published gets derived from it. Deliverables are the compressed files for a specific destination, and they are disposable by design. Confusing the layers is the single most common cause of quality loss over time, because each new version generated from an already compressed file adds another round of artefacts. Frame rate, colour space and audio configuration belong to the master and should be decided once, in writing, rather than defaulted per export.

The order matters more than the tools. Skip a step and you usually notice two steps later — by which point the fix costs several times as much.

What runs differently here

Where this differs from the general case:

• Keep one mezzanine master in an editing codec such as ProRes or DNxHR and derive every published file from it
• Decide frame rate once for the whole project; mixing rates between master and deliverables produces stutter nobody can fix later
• Note the colour space with the file — an SDR master in Rec. 709 and an HDR master are not interchangeable
• Export a textless version and a version without burned-in subtitles if any language work may follow
• File names should carry project, version, format and date, so a colleague can identify a file without opening it

Step by step

This order gets you there fastest:

1. Write down the delivery matrix before exporting anything: which formats, which lengths, which languages, which channels, and who receives each file. Guessing this at export time creates orphan versions.
2. Confirm the technical baseline with the client: resolution, frame rate, colour space, audio channels and loudness target. These five answers determine every export setting that follows.
3. Export the mezzanine master first, in an editing codec at full quality, with the timeline at its native resolution and no platform-specific compromises baked in.
4. Produce a textless version and a clean audio version alongside it. Both cost one extra export today and save a full conform when a language or a partner brand appears later.
5. Derive every deliverable from that master rather than from another deliverable. Each generation of compression on top of compression removes detail that cannot be restored.
6. Verify each exported file by playing it, not by trusting the render log. Check the first and last seconds, audio presence on both channels, and that subtitles appear where expected.
7. Name files with a consistent scheme and include the version. Two files called final are a support ticket waiting to happen, and the second one always wins by accident.
8. Deliver with a short document listing what each file is for, its specification and where it should be published, so the recipient does not have to reverse-engineer the folder.

Common pitfalls

What most often goes wrong in practice:

• Treating the compressed web upload as the archive copy of the film
• Generating a new cutdown from an already compressed deliverable
• Mixing frame rates between master and deliverables and shipping a stuttering version
• Delivering a folder of files named final, final2 and final_really with no accompanying list

With TillyGen

The deliverables list in TillyGen is agreed during planning, so the export session works from a written matrix of formats, lengths and languages instead of a memory of what somebody mentioned in a call.

Change one constraint and the consequences travel through the whole plan: affected shots are flagged, the call sheet is regenerated, and nobody keeps working from yesterday's version.