Skip to main content
Video shows up in two very different shapes, and AdCP models them as two different asset types with opposite rules. Knowing which one you’re holding explains why some video assets need a width and height and others need none at all.

​
Two kinds of video creative

A hosted video file is a concrete encoded file you host — an MP4 you hand over and that gets served directly. It has one resolution, one duration, one codec: the facts are baked into the file. A VAST tag is not a file. It’s a pointer (a URL, or inline VAST XML) to a runtime decision made by a video ad server. When a player calls that tag, the ad server can return several renditions of different sizes and bitrates, an adaptive stream, or an interactive ad — and the player picks the one that fits the screen it’s playing on. The geometry isn’t decided until serve time. These map to the two canonical video formats in the glossary: video_hosted and video_vast.

​
Why a file has dimensions and a tag doesn’t

A hosted video file has an intrinsic native resolution — there is a real, single width and height you can read straight out of the file. So the video asset requires width and height. Requiring them is just recording a fact that already exists; an ad server can’t place the file correctly without them. A VAST tag has no single dimension. Inside the VAST response, each rendition carries its own width and height, and the player selects one at request time. There is no “the tag is 1920×1080” — asking a tag for one pixel size would throw away exactly the flexibility VAST exists to provide. So the vast asset carries no width/height at all. This is deliberate, not an omission. The short version: dimensions belong to a file, not to a tag.

​
Where size and duration rules live

If the asset itself doesn’t carry a shape, how does a seller say “this slot takes 16:9 video up to 30 seconds”? Those are constraints, and constraints live on the format, not the asset:
  • Aspect ratio and orientation (16:9, vertical/horizontal/square)
  • Size ranges (minimum and maximum width/height)
  • Duration ranges (a maximum length, or an exact required duration)
  • Containers and codecs the format accepts
This split is the core idea: an asset describes the content you’re sending; a format describes what a placement will accept. A hosted file is checked against those constraints up front because its facts are known. A VAST tag is checked at serve time, when the actual rendition is chosen.

​
Accepted formats

For a hosted video file, the delivery container is MP4 (H.264 video, AAC audio) — the format every player and ad server supports. Editing/source formats like MOV (QuickTime/ProRes) are mezzanines: convert them to MP4 before delivery. WebM is a browser-playback format, not a delivery creative. For a VAST tag, the container question doesn’t apply to the asset — the renditions and their codecs live inside the VAST response, and the player chooses one that it can play. When in doubt, check the format’s requirements: a format states the containers and codecs it accepts, so an agent can pick the right asset before sending it.

​
How a VAST tag’s fit is confirmed

Because a VAST tag resolves at request time, its fit to a placement is guaranteed at serve time: the player (or the ad server’s creative profile) selects a rendition matching the slot’s size, picks an allowed codec/bitrate, and enforces the duration cap. A check at submission time can only ever be best-effort — a tag can chain through wrappers, return different renditions per request, carry an adaptive manifest, or be an interactive ad with no static rendition to measure. So a dimensionless VAST asset is normal and expected; the matching happens later, where the actual rendition is known.

​
Duration

Duration behaves like dimensions split across the two shapes. A hosted file has an intrinsic duration, so it’s read from the file and carried alongside the dimensions. For a VAST tag, duration is the one whole-ad fact the tag exposes, and the ad server reads it from the tag. Either way, a placement’s maximum length is a format constraint — checked against the file up front, or against the rendition at serve time.