The Video Encoding Guidelines Got Their First Rewrite Since 2022. VAST Only Carries the Claim.

The other document that shipped on 22 July

Two documents came out of the CTV Ad Portfolio process on the same day. The signaling guidance is the one that got written about, including here: it defines how a pause ad or a squeezeback gets traded, and the VAST 4.4 draft schema landed alongside it. The second document is Ad Format Guidelines for Digital Video and CTV v2.0, and it is the first substantial revision of that guidance since June 2022.

It is a different kind of document. Signaling describes the transaction. The guidelines describe the bytes: which codec, which bitrate at which resolution, how loud, what the mezzanine has to be. Produced by the Ad Format Hero Taskforce with contributions from Disney, Google, NBCUniversal and Magnite, it is the closest thing the industry has to a delivery contract for a video ad file.

VAST sits between the two and carries neither. What VAST carries is a set of attributes that assert what the file is. The player reads those attributes, picks a rendition, and starts playback. Nothing between the transcode and the screen checks whether the assertion is true.

What v2.0 actually specifies

Worth reading in full if you own an encoding pipeline, because most of the numbers moved. The ready-to-serve ladder expanded from three options to four, with a dedicated CTV and HD column, and the ranges are now split by environment rather than given as single values.

The numbers to pin to your transcode config

• Ready-to-serve H.264 ladder: 640x360 at 1.5 to 3 Mbps, 854x480 and 960x540 at 2 to 4 Mbps, 1280x720 at 2 to 5 Mbps, 1920x1080 at 4 to 10 Mbps, 3840x2160 at 15 to 30 Mbps. The lower end of each range is for online video, web and mobile. The upper end is for CTV.
• Video codec: H.264 (AVC) High Profile is required. H.265/HEVC, VP9 and AV1 are optional and primarily CTV.
• Audio: AAC-LC required at 128 to 192 kbps stereo, 48 kHz preferred and 44.1 kHz acceptable. Dolby Digital Plus 5.1 is optional for CTV at 256 to 384 kbps.
• Loudness: -24 LKFS plus or minus 2 under ATSC A/85 in the US, -23 LUFS plus or minus 1 under EBU R128 in the EU, true peak at or below -6 dBTP.
• Mezzanine: .mov preferred over .mp4, Apple ProRes preferred with DNxHD and DNxHR accepted, native resolution with no upscaling, 8-bit minimum and 10-bit preferred, PCM audio, and no leaders or slate.
• Frame rates 23.976, 24, 25, 29.97, 30, 50, 59.94 and 60. Aspect ratios 16:9, 1:1, 9:16 and 2.39:1.
• Companion creative around 200 kB for most ads, static display under 350 kB.

That sentence is the whole problem

The guidelines nominate VAST as the place where conformance to all four renditions is expressed. So the XML is where an ad server, an SSAI stitcher and a player each learn what they are about to fetch. And every one of those attributes is an unverified claim.

A MediaFile declares delivery, type, width, height, either bitrate or a minBitrate and maxBitrate pair, and in 4.1 and later a codec and a fileSize. Player selection logic is built directly on those numbers: pick the rendition closest to the display, under the bandwidth ceiling, in a supported container. If the numbers are wrong, the player does not fail, it selects wrong. A file declared at 1920x1080 and 800 kbps will be chosen for a living-room screen and will look like it was chosen for a phone.

The failure mode is the one that makes CTV expensive: nothing errors. The impression bills. The discrepancy shows up weeks later in a quality conversation with no evidence attached, because the only shared record of what the file was supposed to be is a PDF and an XML attribute nobody checked.

That fragment is structurally valid VAST. It passes an XSD. It will play. It is also 800 kbps at 1080p, against a guideline range of 4 to 10 Mbps for that resolution, and it is the only rendition offered, so a CTV player has nothing better to fall back to and a mobile player has nothing lighter. There is no Mezzanine, so an SSAI platform has nothing to transcode from and will either reject the ad or re-encode the already-compressed rendition.

Three separate guideline violations, all of them legible from the XML alone, none of them a VAST spec error.

What the XML can settle on its own

• Declared bitrate against declared dimensions. A 1080p rendition claiming 800 kbps, or a 360p rendition claiming 12 Mbps, is either a bad transcode or a bad declaration, and both are worth failing a build over.
• Whether a ladder exists at all. One rendition means no adaptive choice for any player on any connection. The guidelines expect four ready-to-serve versions.
• Mezzanine presence and completeness. vastlint raises VAST-4.1-mezzanine-recommended when MediaFiles has no Mezzanine, which ad-stitching servers reject in CTV and SSAI contexts, and VAST-4.1-mezzanine-delivery, -type, -width and -height when the element is there but underspecified.
• Bitrate declaration coherence. VAST-3.0-minmaxbitrate-pair catches a minBitrate without its maxBitrate, and VAST-3.0-bitrate-conflict catches a file declaring both a fixed bitrate and a range, which leaves the player to guess which one is real.
• The structural floor. VAST-2.0-mediafile-delivery, -type and -dimensions cover the attributes a selection algorithm cannot work without, and VAST-2.0-mediafile-delivery-enum catches a delivery value that is neither progressive nor streaming.
• Transport. VAST-2.0-mediafile-https flags a media file on plaintext HTTP, which mixed-content policy blocks outright on secure inventory regardless of how good the encode is.
• Aspect ratio sanity. Declared width and height that reduce to none of 16:9, 1:1, 9:16 or 2.39:1 will be letterboxed or cropped by somebody downstream, and which one you get is not specified anywhere.

What the XML cannot settle, and pretending otherwise helps nobody

A VAST validator reads XML. It does not open the mp4. Four of the requirements in v2.0 are invisible to it, and they are not minor ones.

Loudness is the obvious case. The -24 LKFS target exists because viewers reach for the remote when an ad is louder than the programme, and nothing in a VAST document says how loud the file is. Codec profile is the second: codec="avc1.640028" claims High Profile at Level 4.0, and an encoder that actually emitted Main Profile produces the same attribute string with a different reality. Bit depth and the no-slate rule for mezzanines are the other two.

Those need the asset. The honest split is to run declaration checks in CI, where they are free and catch the majority of what actually breaks, and probe the file once at creative ingest, where it is cheap because it happens per creative rather than per impression.

Why this lands now rather than in a quarter

The six CTV Ad Portfolio formats change the shape of the creative. A pause ad can now carry video rather than a JPEG, an overlay occupies a corner rather than the frame, a squeezeback shares the screen with resized content. Each of those has different encoding implications, and the guidelines were rewritten in the same cycle for exactly that reason.

At the same time the buying side is being automated. An agentic buyer negotiating a pause ad will not open the tag and eyeball the renditions, and the format signal it trades on says which format was bought, not whether the file behind it conforms to the guideline that governs that format. The gap between the signal and the asset is the gap a validator exists to close.

None of this requires waiting for VAST 4.4 to be published. Every check above works against 4.0 through 4.3 tags in production today.

The audit worth running this week

• Pull a sample of live tags and list every declared bitrate against its declared resolution. Anything outside the v2.0 range for its tier is a finding, in either the encode or the declaration.
• Count renditions per creative. Anything shipping one MediaFile to CTV inventory is shipping no fallback.
• Check for Mezzanine on every tag that reaches an SSAI path, and confirm delivery, type, width and height are all present when it is.
• Grep for http:// in media file URLs. It is still there more often than anyone expects.
• Add an ffprobe and ebur128 pass to creative ingest for the four things the XML cannot see, and record the result next to the tag so a discrepancy conversation has evidence in it.