How to Get Video Delivery Specifications Right

Video delivery specifications are the technical requirements a client, broadcaster or platform sets for a finished file: the codec, the container, the resolution, the frame rate, the scan type, the bit depth, the audio layout, the loudness target and the metadata that travels with it. They are usually a PDF or a web page of a few pages to a few dozen, and they read like a contract, because in practice they are one. If the file does not match, the recipient is entitled to send it back, and most of them do so automatically.

This guide is for the people who have to live with that document: producers and marketers commissioning video, in-house editors who suddenly have a broadcast or streaming deliverable on their plate, and post-production teams who want fewer rejected files. A rejected delivery costs a day and sometimes a slot, and almost every rejection is for something that was written down in advance and not read carefully. The good news is that getting specifications right is mostly a matter of habit and order of operations, not specialist genius.

What follows moves from fundamentals to advanced practice: what a specification covers, how to read one, each technical field in turn, how to check a master before it leaves, how to serve several destinations from one master, and what to do when a file comes back.

What Video Delivery Specifications Actually Cover

A delivery specification describes a file, not a film. It says nothing about whether the story works; it describes the container the story has to arrive in so that the recipient's systems can ingest, play out, stream or archive it without human intervention. That is the key to reading one well: every line exists because some machine downstream expects it.

Most specifications, whatever the destination, are organized around the same families of requirements.

Video essence

The picture itself: the codec and its profile, the data rate or quality level, the resolution, the aspect ratio, the frame rate, whether the picture is progressive or interlaced, the chroma subsampling (4:2:0, 4:2:2 or 4:4:4), the bit depth (8, 10 or 12 bits), the color space and transfer function (Rec. 709 for standard dynamic range HD, Rec. 2020 with PQ or HLG for HDR), and the signal range, meaning whether the file must stay within broadcast-legal levels.

Audio essence

The sample rate (almost always 48 kHz for professional video), the bit depth (typically 24-bit), the number of tracks and what each one carries, the loudness target and measurement method, the true-peak ceiling, and sometimes the maximum short-term loudness or loudness range.

Wrapper and structure

The container (QuickTime MOV, MXF, MP4 and so on), the start timecode, whether the file needs bars and tone, a slate, a countdown or black at head and tail, whether programme breaks are marked, and how long each element should be.

Metadata and ancillary deliverables

Embedded metadata fields, sidecar files such as captions or subtitles, a separate music and effects mix, textless versions of any shots with on-screen text, thumbnails or key art, cue sheets and paperwork. On large projects the ancillary list is often longer than the list of picture requirements, and it is where schedules quietly slip.

For a streaming platform, the published partner documentation is usually the definitive source; the Netflix Partner Help Center's delivery specifications are a good example of how detailed a platform will be about every one of these families, and worth reading even if you never deliver to Netflix, because they show what a complete specification looks like.

Reading the Specification Before the Edit Begins

The most useful single habit in delivery work is to read the specification before the edit begins, not before the export. By export time, the decisions that matter have already been made: the project frame rate, the timeline resolution, the color pipeline, the way audio stems were built. If any of them conflict with the specification, fixing them at the end means conversion, re-conforming or re-mixing, each of which costs time and usually quality.

Read the document once end to end, then go through it again with a highlighter and turn it into a one-page delivery sheet for the project. That sheet travels with the job and is what the editor, colorist, mixer and whoever runs quality control actually work from.

Questions to settle at kickoff

• Which version of the specification applies? Platforms and broadcasters revise documents, and a PDF saved on a shared drive two years ago may be out of date.
• What is the source frame rate, and does the specification accept it? If the camera shot 25 fps and the destination wants 23.976, that is a decision to make on day one, not in the last hour.
• Which color space and dynamic range are required, and is an HDR master expected alongside an SDR one?
• How many audio versions are needed: a full mix only, or also stems, a music and effects track, or a described-audio mix?
• What ancillary files are required, and in which formats?
• How is delivery made: upload to a portal, file transfer service, physical drive, or a review platform?

Never assume this client's specification matches the last one. Two broadcasters in the same country can differ on start timecode, audio track order and the length of black at the tail, and a platform that accepted a file last year may reject the same settings today. Our guide to video editing workflow decisions covers how to set up a project so these choices are made once, early, and propagate through every stage.

Codecs, Containers and Wrappers

People often use "format" loosely to mean everything about a file, but specifications separate two things: the codec, which compresses the picture and sound, and the container or wrapper, which holds the compressed streams together with timecode and metadata. A ProRes file in a MOV wrapper and a ProRes file in an MXF wrapper contain the same picture data but are not interchangeable as deliverables.

Mezzanine and master codecs

For masters and professional handoffs, specifications typically ask for an intraframe codec that preserves quality through further processing: Apple ProRes (422 HQ, 4444 or 4444 XQ), Avid DNxHR or DNxHD, or broadcast-specific formats such as XDCAM HD 422 at 50 Mb/s or AVC-Intra in an MXF wrapper. Some broadcasters define a complete profile rather than just a codec; the UK's DPP AS-11 specification, for example, pins down codec, wrapper, audio layout and a mandatory metadata set in one document. At the high end, feature and series work increasingly uses IMF packages, the Interoperable Master Format standardized by SMPTE, which separates a master into components and lets versions share essence rather than duplicating it.

Distribution codecs

For web and social delivery, the recipient usually wants a long-GOP file that is already close to what viewers will stream: H.264 or H.265 (HEVC) in an MP4, occasionally AV1 or VP9. The specification may set a maximum data rate, a profile and level, a keyframe interval, or simply a file size cap. If you deliver H.264 regularly, our piece on H.264 video done properly covers the encoder settings that matter, including why a two-pass variable-bit-rate encode is usually the right default for a file that will be re-encoded by the platform anyway.

Where wrappers trip people up

MXF in particular comes in several operational patterns (OP1a and OP-Atom are the common ones), and a recipient expecting OP1a with interleaved audio will not ingest OP-Atom with separate audio files. Within MOV and MP4, the problems are usually metadata: missing or wrong color tags, a timecode track that starts at zero when the specification says 10:00:00:00, or audio tracks labeled incorrectly. The SMPTE file format and metadata standards are the underlying reference for MXF and IMF, and most broadcaster documents cite them by number; when a requirement says "compliant with SMPTE ST 377", that is the MXF file format standard and your encoder needs to produce it properly, not approximately.

The table shows typical patterns, not rules; the specification you receive is the only authority for your delivery.

Resolution, Scan Type and Frame Rate

These three fields define the geometry and timing of the picture, and they are where late changes do the most damage.

Resolution and aspect ratio

Specifications usually give an exact pixel raster: 1920 x 1080, 3840 x 2160 (UHD), 4096 x 2160 (DCI 4K) and so on. UHD and DCI 4K are not the same thing, and a platform asking for 3840 x 2160 will reject 4096 x 2160. Watch for how the specification treats content with a different aspect ratio: most want the active picture letterboxed or pillarboxed inside the full raster rather than delivered at a non-standard size, and some state the exact active image area they expect. Our overview of video resolutions and 4K standards explains the differences and when each raster is appropriate.

Upscaling to meet a resolution requirement is sometimes acceptable and sometimes explicitly forbidden. Premium platforms often require that a stated share of the programme originate at the delivery resolution, and they may check for it. Read the section on source requirements before deciding to shoot HD and upscale.

Scan type

Progressive delivery is now the norm, but some linear broadcasters still carry interlaced HD (1080i at 25 or 29.97 frames per second). The specification will say which, and for interlaced delivery it will also specify field dominance, usually upper field first for HD. Delivering progressive content flagged as interlaced, or the reverse, causes combing or judder on air and is a common automated QC failure.

Frame rate discipline

The rule is simple: deliver at the source rate wherever possible, because frame rate conversion introduces artifacts. Converting 25 fps to 29.97 fps, or 23.976 to 25, means either duplicating and dropping frames (which produces visible judder), blending frames (which produces ghosting), or motion-compensated interpolation (which can produce warping artifacts on complex motion). None of them is invisible on demanding material.

That is why frame rate belongs in the kickoff conversation. If the destination needs 23.976 and the production is in a 50 Hz country, shoot at 23.976 if you can. If you cannot, agree up front whether the destination will accept the native rate. The mistake to avoid is converting frame rate late to meet a specification nobody checked, which forces a conversion on a finished, graded, mixed programme and can knock audio out of sync if it is done carelessly.

Also check whether the specification wants drop-frame or non-drop-frame timecode for 29.97 and 59.94 material. The picture is identical, but the timecode labels differ, and a file with the wrong timecode type will fail a check even when every frame is perfect.

Color Space, Bit Depth and Signal Levels

Color requirements have become more demanding as HDR has spread, and they are one of the fields most likely to be misunderstood by teams who mostly deliver to the web.

Color space and transfer function

For standard dynamic range HD and UHD, the default is Rec. 709 primaries with a BT.1886 display transfer function, though many specifications simply say "Rec. 709". For HDR, you will see Rec. 2020 primaries with either PQ (SMPTE ST 2084) or HLG. PQ masters usually require static metadata (mastering display information, MaxCLL and MaxFALL) and sometimes Dolby Vision dynamic metadata as a sidecar XML. HLG is common for broadcast because it degrades gracefully on SDR displays. If HDR is on the list, read our guide to HDR video delivery done properly before the grade starts, since the choice between PQ and HLG and the order in which you create HDR and SDR versions shape the whole finishing pipeline.

Whatever the color space, the file must also be tagged correctly. A Rec. 709 file tagged as unspecified, or an HDR file missing its transfer characteristics, may display wrongly and will fail automated checks. Confirm the tags with a tool such as MediaInfo rather than trusting the export dialog.

Bit depth and chroma subsampling

Masters are usually 10-bit 4:2:2 or better; 8-bit 4:2:0 is a distribution format. Delivering an 8-bit master where 10-bit is required fails the specification, and it also costs quality: gradients such as skies and studio backgrounds band visibly after the platform's own encode. HDR delivery effectively requires 10-bit or higher.

Legal range and gamut

Broadcast specifications typically require the signal to stay within legal range: in 10-bit video, luma between code values 64 and 940, with defined tolerances for brief excursions. Many also set limits on out-of-gamut color, which matters for saturated reds and blues in graphics. The practical approach is to monitor with scopes during the grade, apply a broadcast-safe limiter as the last node, and let the automated QC confirm the result. A limiter applied blindly at the end can clip highlights harshly, so treat it as a safety net, not a substitute for grading within range.

Confirm frame rate and color space at the start of the project, together. They are the two decisions that are expensive to reverse, and they are often set by default in editing software in ways nobody deliberately chose.

Audio Layout, Track Order and Loudness

Audio causes a disproportionate share of rejections, largely because it is specified in more exact terms than many teams expect, and because problems are easy to miss when you watch a file on laptop speakers.

Channel assignment and track order

Specifications usually state the audio layout exactly: how many tracks, how many channels per track, and what goes on each. An illustrative layout for a broadcast master might be: tracks 1 and 2, stereo full mix left and right; tracks 3 and 4, stereo music and effects; tracks 5 to 10, a 5.1 mix in the order L, R, C, LFE, Ls, Rs; remaining tracks silent or carrying described audio. Another recipient might want the 5.1 first and the stereo second, or discrete mono tracks rather than stereo pairs, or everything in a single multichannel track.

Never guess at channel assignment. The 5.1 channel order alone has more than one convention in use, and a centre channel swapped with the LFE sends dialogue to the subwoofer. If the specification is unclear, ask in writing, and keep the answer with the project.

Loudness targets

Loudness is measured in LUFS (or LKFS, which is the same scale under a different name) using the ITU-R BS.1770 algorithm. In Europe, broadcast loudness is commonly -23 LUFS under EBU R 128, with a maximum true peak that R 128 sets at -1 dBTP. The European Broadcasting Union's technical documentation publishes R 128 and its supplements, including guidance on loudness range and short-form content, and it is worth reading the primary document rather than a summary. In the United States, broadcast follows ATSC A/85, which targets -24 LKFS. Streaming platforms set their own targets, some measuring the whole mix and some measuring only dialogue, and those targets differ from broadcast.

The practical consequence is that one mix rarely serves every destination. A web mix balanced by ear to sound competitive on a phone will typically measure far louder than -23 LUFS and fail a broadcast check outright. Mix to the target with a loudness meter on the master bus, and create separate loudness-normalized versions for destinations with different targets rather than turning one file up or down.

Sample rate, sync and silence

Professional video audio is 48 kHz, and a 44.1 kHz track exported from a music session is a common and avoidable failure. Check sync at the head, middle and tail of the programme, not just the first minute: drift from a sample-rate mismatch accumulates and may be invisible early on. And make sure any tracks the specification calls "silent" really are silent, not carrying a faint copy of the mix from a routing mistake.

Metadata, File Naming and Ancillary Deliverables

A file can be technically perfect and still be rejected because it is called the wrong thing or arrives without its companions.

File naming

Name files exactly as the specification requires. Many recipients ingest by filename, so a name that does not match the expected pattern may never be matched to the right order or episode. Naming conventions often encode the programme ID, episode number, version, language, resolution and audio configuration, in a fixed order with fixed separators. Follow them character for character, including case, and avoid spaces and special characters unless explicitly allowed.

Embedded metadata

Broadcast profiles such as AS-11 require specific descriptive metadata inside the file: programme title, episode title, identifiers, duration, and the timecode of each part if the programme is segmented for breaks. The metadata must match the content; a declared duration that is off by a few frames is enough to fail. Streaming and corporate specifications are usually lighter here, but color tags, timecode and audio channel labels still count as metadata and are still checked.

Ancillary files

Typical ancillary requirements include caption or subtitle files (SRT, WebVTT, SCC, IMSC or EBU-TT, depending on destination), a textless version or textless tail for localization, music cue sheets, a music and effects mix, and still images or thumbnails at specified sizes. Captions deserve particular care, because they must be timed to the delivered frame rate; a caption file timed to a 25 fps edit will drift against a 23.976 fps master. On regulated subjects, ancillary requirements extend into approval records and reference documentation; our article on pharmaceutical video requirements shows how much paperwork can surround a single file in a regulated sector.

Quality Control Before the File Leaves

Automated quality control is standard for broadcast delivery, and most large platforms run their own checks on ingest. That does not make your own QC optional; it makes it more important, because the recipient's system will find what you missed and the round trip costs days. Run a quality-control check on the master before sending it, every time.

Automated checks

Automated QC tools inspect a file against a template: they verify codec, wrapper, resolution, frame rate and audio layout; measure loudness and true peak; detect out-of-range video levels, black frames, frozen frames, silence and digital hits; and check timecode continuity and metadata fields. Several commercial QC products ship with templates built from common broadcaster specifications. For smaller operations, a combination of MediaInfo for the file structure, a loudness meter that measures the whole file offline, and scopes in the grading software covers most of the same ground, with more manual effort.

Human checks

Automated tools do not catch everything. They will not notice a spelling mistake in a lower third, a shot that was meant to be replaced, a caption that is correctly timed but wrong, or a flash frame left in at a cut if it is within legal levels. Never deliver a file that has never been played back in full. Someone should watch the actual exported file, not the timeline, from first frame to last, on a calibrated or at least well-understood display, with good headphones or speakers.

If you want a deeper treatment of how to set QC up as a repeatable stage rather than a last-minute scramble, our guide to video quality control done properly walks through templates, sign-off and what to do with a QC report that shows warnings rather than failures.

Worked Example: One Master, Three Destinations

The following project is illustrative, built to show how the decisions interact; the figures are realistic but not from a specific client.

A company has commissioned a 30-minute documentary about its sector. It will air on a European broadcaster, be offered to a streaming service, and be cut down into a 90-second trailer for the company's own website and social channels. The shoot is in Europe.

Reading the three specifications on day one

The broadcaster wants 1080i25 in an MXF OP1a wrapper with a 10-bit intraframe codec, stereo full mix on tracks 1 and 2 and M&E on tracks 3 and 4, loudness at -23 LUFS with a true peak ceiling of -1 dBTP, start timecode 10:00:00:00 and specified descriptive metadata. The streaming service accepts 25 fps native content and wants a UHD ProRes 422 HQ master in Rec. 709, a 5.1 mix plus stereo, a textless version and subtitle files. The website wants an H.264 MP4 at 1920 x 1080, under a stated file size, with burned-in captions for social and a separate caption file for the site player.

Decisions made before shooting

• Shoot at 25 fps progressive in UHD. Both long-form destinations accept 25 fps, so no frame rate conversion is ever needed, and the 1080i25 broadcast version is derived from a progressive master, which interlaced broadcast handles cleanly as progressive segmented frames.
• Grade in Rec. 709 SDR, since neither long-form specification asks for HDR. Adding HDR later would mean a second grading pass, so the question is asked and answered in writing now.
• Keep all on-screen text on separate graphics layers so a textless version can be exported without re-editing.
• Mix in 5.1 with a stereo fold-down checked by ear, plus an M&E, with dialogue, music and effects stems kept separate.

The masters produced

One UHD 25p ProRes 4444 master is created from the finished timeline and archived; every deliverable is made from it. From that master: a UHD ProRes 422 HQ file for the streamer with the 5.1 and stereo mixes; a textless UHD file; a downscaled 1080 broadcast file in the specified MXF wrapper with the stereo mix and M&E, loudness-normalized to -23 LUFS; and the trailer, edited separately but conformed from the same media and exported as H.264.

At ProRes 422 HQ's target data rate for UHD 25p, roughly 590 Mb/s, the 30-minute streaming master alone lands at around 130 GB, and the 4444 archive master is larger still. Those sizes drive transfer time and storage planning: at a sustained 100 Mb/s upload, 130 GB takes roughly three hours, so delivery windows must allow for it, and a failed transfer on the deadline day is its own kind of rejection. Our guide to video file storage planning covers how to budget for masters, versions and archive copies.

What QC catches

Automated QC on the broadcast file flags two short luma excursions above 940 in a bright exterior and a true peak of -0.6 dBTP on a music sting. The colorist pulls the highlights in the grade rather than relying on a hard clip, the mixer rides the sting down, and only the broadcast deliverable and the master are re-exported, because the source timeline and stems were kept. The full-length watch-down of the streaming file then catches a caption that runs two seconds past a cut, something no automated check would flag.

Serving Several Destinations and Planning Re-Deliveries

The worked example shows the central strategy: make one high-quality master at the highest resolution and quality any destination needs, then derive every deliverable from it. The master should be at the native frame rate, in the highest required color space, at or above the highest required bit depth, with audio kept as separate mixes and stems.

Keep the mastering file

Keep the mastering file, and the project that made it, so a re-delivery does not mean a re-render from scratch. Recipients ask for re-deliveries more often than teams expect: a corrected caption, a legal change to a lower third, a new audio version, a different loudness target when the programme is resold to another territory. If only the delivered broadcast file survives, each of those becomes an expensive reconstruction. If the master, the project and the stems survive, most changes are a patch and a re-export.

Version control for deliverables

Give every delivered file a version identifier and keep a simple delivery log: what was sent, to whom, when, with which checksum, and what the QC report said. When a recipient comes back three months later saying the file has an audio problem, the log tells you which version they are talking about. Sharing review copies through a controlled platform helps here too; our practical guide to private video review and sharing covers how to keep watermarked review copies separate from actual deliverables so the wrong file never gets sent.

When destinations are incompatible

Some combinations cannot be satisfied from a single timeline without compromise: a 29.97 fps US broadcast and a 25 fps European broadcast from the same source, an HDR platform master and an SDR broadcast version, or a vertical social cut and a widescreen programme. In those cases, plan the conversion or the second version deliberately, using the best tool for it, and schedule the time for proper checking. The mistake is not converting; it is converting at the last minute without testing the result.

Once files are delivered, what happens next is often out of your hands, but for content you publish yourself, the scheduling and platform choices covered in publishing and scheduling video determine how much of the care you put into delivery actually reaches viewers.

When a Delivery Is Rejected, and When to Bring in Help

Rejections happen even to careful teams. How you handle one decides whether it costs an afternoon or a week.

Responding to a rejection

Read the rejection report in full before touching anything. Automated reports list every failure with a timecode and a measured value; fix every item, not only the first, because a second rejection for something already on the first report is the most avoidable delay there is. Identify whether each problem lives in the master or only in the deliverable: a loudness failure in a derived file might be fixable by re-normalizing, while an out-of-range highlight is a grading fix that should go back into the master so future versions inherit it. Then re-run your own QC before resubmitting, and note in your delivery log what changed.

Common rejection causes and their fixes

• Loudness out of tolerance. Re-measure the whole file offline, correct the mix or apply gain to the specific version, and check the true peak afterwards, since raising gain can push peaks over the ceiling.
• Illegal video levels. Correct the offending shots in the grade, then apply a limiter as a safety net, not as the fix.
• Wrong audio track order. Re-wrap with the correct channel mapping; the mix itself does not need to change.
• Incorrect metadata or timecode. Usually fixable by re-wrapping, without re-encoding the picture.
• Frame rate or raster mismatch. The expensive one. Assess whether a proper conversion is acceptable to the recipient before doing it, and check the result frame by frame on motion-heavy scenes.

When to bring in help

Bring in help when a delivery has been rejected and the report is not clear to you, when a broadcast specification is unfamiliar, or when one master must satisfy several incompatible destinations. Those are the situations where experience with the specific profile and access to proper QC tools save the most time. A post-production partner that delivers to these destinations routinely will have templates, presets and a checklist already built, and can often turn a rejected file around within the recipient's window. If that is where you are, our video editing and production services cover finishing, mastering and delivery to broadcast, streaming and web specifications.

The other time to bring in help is earlier than most people think: at kickoff, when a specification is first received. An hour spent turning the document into a delivery sheet and checking the camera, project and mix settings against it is cheaper than any conversion or re-mix that follows from skipping that hour.

Where this comes from

• Netflix Partner Help Center — Delivery specifications
• European Broadcasting Union — Delivery and quality control
• SMPTE — File format and metadata standards

The figures and practices above come from the sources listed.

Working on something like this?

We take on Video Editing & Production work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.

Where to go next

• How to Get Multi-Camera Editing Right
• Video Analytics and Retention, Done Properly