> ## Documentation Index
> Fetch the complete documentation index at: https://docs.interchange.io/llms.txt
> Use this file to discover all available pages before exploring further.

# How AdCP thinks about video

> Why a hosted video carries pixel dimensions but a VAST tag doesn't — and where size, duration, and format rules actually live.

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](/v2/concepts/glossary): `video_hosted` and `video_vast`.

<Note>
  **The asset must match the format.** A raw video file (MP4) is a
  `video_hosted` asset — it is not a VAST tag, and labeling it `video_vast`
  does not make it one. A `video_vast` creative must carry an actual VAST
  document (a tag URL or inline VAST XML). A raw file sent under a `video_vast`
  label is not AdCP-schema compliant: publishers that validate schema reject
  the buy, and others silently drop the creative. If all you have is a hosted
  file, use `video_hosted`; reserve `video_vast` for a real VAST tag.
</Note>

## 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.