Volume navigation
VMAP · Video Multiple Ad Playlist
VMAP 1.0.1 · official XSD baselineOn this page
Why VMAP exists
Inserting ads into a video playback involves two things: defining the structure of the ad inventory — where the breaks are, how many, how many ads each may play — and defining the ads that fill them. VAST solves the latter. When content plays in its owner's player, the former is managed directly; once content is syndicated into someone else's player, the former has no owner.
Business arrangements between content owner and distributor may grant the owner the right to manage its ad inventory, but without control of the player or the distribution outlet that right cannot be exercised. VMAP turns it into a machine-readable break playlist: when to insert, which types, how many per break, whether to repeat.
VMAP does not define the ads themselves. It wraps one or more ad responses (designed for VAST 3.0, accepting other formats too), so it complements rather than replaces VAST: VAST can be served without VMAP, and VMAP only matters when the content owner lacks player control but holds the right to control the advertising experience inside its content.
Three parties hold distinct responsibilities in a VMAP interaction; this volume is organised along the same axis:
- Content owner / primary ad server: defines the break playlist (count, timing, types, ads per break)
- Secondary ad server: supplies the ad response filling a break via AdTagURI
- Video player: executes breaks at timeOffset, requests tracking URIs, substitutes error macros
Why it stopped at 1.0.1
VMAP's revision history is short: one release, one typo-sized patch, then long stability. Reading it in order confirms which version to treat as authoritative today.
Act I · Drafting: content owners reclaim ad-inventory control
Syndication put content into players its owner does not control; VAST 3.0 governed the ads but not the timing of the breaks — that was the gap.
- VMAP 1.0 released (Original). Drafted by a volunteer working group of 42 IAB member companies, led by Adap.tv, Google/YouTube and FreeWheel· last-verified 2026-09-22
Act II · Revision: a typo-sized patch
1.0.1 corrected typos in two sections only, yet it also settled the official name VASTAdData — a small patch worth ingesting all the same.
- VMAP 1.0.1 released: typo corrections in sections 4 and 5 only (the official Updates table writes 1/x/2014, day missing); the XSD annotation confirms VASTAdData as the correct element name from this version· last-verified 2026-09-22
- The current PDF was exported from Word 2010 (metadata CreationDate) — the version this site transcribes· last-verified 2026-09-22
Act III · Present: long-stable with no successor
The official repository stopped in 2015 and the specification at 1.0.1 — for debugging legacy chains it remains the only authority.
- The IAB GitHub vmap repository gains the official XSD (commit 5412bbe, prepared by FreeWheel); no commits since· last-verified 2026-09-22
- This site's check: no revision or successor after 1.0.1 in official channels; VMAP remains part of the IAB video suite and 1.0.1 is the reference for legacy-chain debugging· last-verified 2026-09-22
The four steps of a VMAP interaction
The serving process of specification §1.3: request, response, playback, tracking.
- 1VMAP requestThe player requests a VMAP response from the primary ad server
- 2VMAP responseThe primary server returns the break playlist; each break inlines or references a VAST ad response
- 3Play breaksThe player executes the ads at the VMAP-specified times, per the VAST guidelines
- 4Tracking pingsOn events the player requests the VMAP-level tracking URIs (breakStart / breakEnd / error)
Relations between the parties
The VMAP domain has few participants and linear relations: requests, declares, fills, redirects, tracks, complements. The table below is equivalent to the flow above, with sources for each row.
| From | Relation | To | Note | Source |
|---|---|---|---|---|
| Video player | requests (player → primary ad server) | Primary ad server | The player requests a VMAP response from the primary ad server | sources/vmap-1.0.1.md §1.3 |
| VMAP response | declares (VMAP response → breaks) | Ad break | The VMAP response declares the break playlist: count, timing, types | sources/vmap-1.0.1.md §2.1 |
| VAST response | fills (VAST response → break) | Ad break | A VAST response fills the break: inline or referenced via AdTagURI | sources/vmap-1.0.1.md §1.1 |
| Primary ad server | redirects (primary → secondary ad server) | Secondary ad server | When the primary server does not manage the ads itself, AdTagURI redirects the player to a secondary ad server | sources/vmap-1.0.1.md §1.2 |
| Video player | tracks (player → tracking URI) | VMAP tracking URI | On break events the player requests the VMAP-level tracking URIs (breakStart / breakEnd / error) | sources/vmap-1.0.1.md §2.3.3 |
| VMAP specification | complements (VMAP ↔ VAST) | VAST specification | VMAP complements rather than replaces VAST: VMAP owns inventory structure, VAST owns the ads; VAST can be served without VMAP | sources/vmap-1.0.1.md §1.1 |
Versions and current status
VMAP has no successor: the official repository has no commits after 2015. Legacy-chain debugging treats 1.0.1 as authoritative; note the root version attribute still reads 1.0 in the 1.0.1 document.
| Version | Release date | Change | Status |
|---|---|---|---|
| 1.0.1 | 2014-01 | Typo corrections in sections 4 and 5 only (including VASTData → VASTAdData); the official Updates table dates it 1/x/2014 with the day missing, which this site does not invent | Current |
| 1.0 | 2012-06-29 | Original | Superseded |
Who owns what
VMAP is published by the IAB Digital Video Committee; the XSD was prepared by FreeWheel and ships with the IAB GitHub repository. Confirm whom to trust before reading any artefact.
| Publisher | Owns | License |
|---|---|---|
| IAB (Digital Video Committee) ↗VMAP was drafted by a working group of volunteers from 42 IAB member companies, led by Teg Grenager (Adap.tv), Payam Shodjai (Google/YouTube) and Michael Evangelista (FreeWheel); IAB leads were Chris Mejia and Katie Stroud |
| © 2014 Interactive Advertising Bureau |
| IAB GitHub organisation (vmap repository) ↗The XSD annotation is signed “xml schema prepared by FreeWheel”; the repository has no commits after 2015-01-29 |
| 未随仓库声明 |
| FreeWheel ↗One of the working-group leads; the XSD authorship appears only in the XSD annotation |
| — |
Core terms
A dozen terms are unavoidable when reading VMAP. Ad Break and Ad Pod mean different things in VMAP and VAST contexts; the definitions state which.
Ad Break
A location or point in time where one or more ads may be scheduled for delivery; in VMAP 1.0 it specifically denotes the technical format and expectations defining the break
Ad Pod
A sequence of linear ads played back-to-back, like a TV commercial break with multiple spots; in this document it denotes the VAST 3.0 Ad Pod compliance format
Ad Response
A formatted ad definition providing display details, returned when ads are requested from another system, usually the publishing organisation supplying the digital space; one formatted in VAST is a VAST response
Ad Response Template
The formal guidelines defining how to structure the creative details in an ad response, so ads served from otherwise incompatible systems can still be received
Content Video
The entertaining content video a publisher provides its audience; typically monetised by inserting ads at timed points along its timeline
Playlist
A structured list of ad breaks within video content — a VMAP response is itself a playlist
Primary Ad Server
The first ad server to receive a request for ads from a browser or video player
Secondary Ad Server
An ad server to which a primary ad server redirects a player or browser to retrieve ads when the primary does not directly manage them
VMAPVideo Multiple Ad Playlist
IAB Video Multiple Ad Playlist: the XML template letting content owners describe ad-inventory insertion structure when they do not control the player
timeOffset
Required AdBreak attribute: break timing, in one of four notations hh:mm:ss[.mmm] / n% / start|end / #m
breakType
Required AdBreak attribute: ad types the break accepts, linear / nonlinear / display, comma-separated for multiple values
templateType
Required attribute of AdTagURI and CustomAdData: the ad response template employed (vast1/vast2/vast3/proprietary; prose also lists vast)
Recommended reading path
To understand the domain systematically, read in this order: structure overview → breaks → ad sources → error codes → example.