VAST 3.0 — Linear Ad With Companion Banners
A VAST 3.0 response pairing a linear spot with two companion banners in the standard IAB sizes, at the older schema version many ad servers still emit. Companions render alongside the video rather than in it, so they exercise a separate slot-matching path — the player has to find a matching container or correctly ignore them when required is none. All URLs point at example.invalid.
<?xml version="1.0" encoding="UTF-8"?>
<VAST version="3.0">
<Ad id="novus-companion-sample">
<InLine>
<AdSystem>Novus Examples Sample</AdSystem>
<AdTitle>Fictional spot with companions</AdTitle>
<Impression><![CDATA[https://example.invalid/imp]]></Impression>
<Creatives>
<Creative sequence="1"><Linear>
<Duration>00:00:15</Duration>
<MediaFiles>
<MediaFile delivery="progressive" type="video/mp4" width="640" height="360" bitrate="700">
<![CDATA[https://example.invalid/spot.mp4]]></MediaFile>
</MediaFiles>
</Linear></Creative>
<Creative sequence="2"><CompanionAds required="none">
<Companion id="c1" width="300" height="250">
<StaticResource creativeType="image/png"><![CDATA[https://example.invalid/300x250.png]]></StaticResource>
<CompanionClickThrough><![CDATA[https://example.invalid/click]]></CompanionClickThrough>
</Companion>
<Companion id="c2" width="728" height="90">
<StaticResource creativeType="image/png"><![CDATA[https://example.invalid/728x90.png]]></StaticResource>
<CompanionClickThrough><![CDATA[https://example.invalid/click]]></CompanionClickThrough>
</Companion>
</CompanionAds></Creative>
</Creatives>
</InLine>
</Ad>
</VAST>
Specifications
- Standard
- VAST 3.0
- Linear Duration
- 00:00:15
- Companions
- 2
- Companion Sizes
- 300x250, 728x90
- Required
- none
- Urls
- example.invalid — never resolvable
What is a .xml file?
XML (Extensible Markup Language) is a verbose, self-describing markup language using nested tags, attributes, and namespaces to represent structured, hierarchical data. It supports schemas, entities, and validation and underlies many document and data formats. It remains common in enterprise, publishing, and interchange contexts.
How to use this file
Use an example XML file to test parsers, namespace and schema validation, XPath queries, and protection against entity-expansion and external-entity attacks.
How to use this file for testing
“VAST 3.0 — Linear Ad With Companion Banners” is a deterministic Novus Examples fixture for Ad insertion, Streaming manifests, Video QA. VAST ad responses and SCTE-35 splice descriptors covering linear break signalling, wrappers, and companion creatives — for testing ad-decision integration and manifest-manipulation logic without calling a real ad server.
Documented properties for this file: XML · 1,370 bytes. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Media fixtures are short and synthetic by design. Prefer waveform or transcript ground truth in the same group when measuring ASR, trim, upscale, or sync tools; do not assume broadcast-quality masters.
Code examples
import xml.etree.ElementTree as ET
tree = ET.parse("vast-companion.xml")
root = tree.getroot()
print(root.tag, [c.tag for c in root][:5])Related files
- mpdDASH — Dynamic (Live) Manifest With a Time-Shift BufferA live DASH manifest: type is dynamic, there is no total duration, and the client must compute which segment is currently available from availabilityStartTime, the wall clock, and the segment duration. Declares a one-minute time-shift buffer and an eight-second presentation delay. The timestamps are fixed so the fixture stays deterministic — a real client will compute a segment number far in the future, which is itself a useful edge case to handle gracefully.
- mpdDASH — Explicit SegmentList AddressingThe same content addressed with an explicit SegmentList — every segment URL enumerated rather than derived from a template. Verbose, but it is what older packagers emit and it permits non-uniform segment naming. A DASH client must support both this and SegmentTemplate; the paired template manifest in this group is the direct contrast.
- mpdDASH — Intentionally Corrupt: Malformed ISO 8601 DurationAn intentionally corrupt DASH manifest whose mediaPresentationDuration is the bare number 14.0 instead of the ISO 8601 form PT14.0S. The XML is well-formed, so it parses cleanly and only fails at schema validation — which most players skip. The usual result is a duration of zero or NaN and a seek bar that never populates, with no error anywhere.
- mpdDASH — Multi-Period Manifest With a Mid-Roll BreakThree DASH periods — content, an ad break, then content again — each with its own initialisation segment. Period boundaries are where players most often break: the decoder must be reset, the buffer cannot span the discontinuity, and rendition selection restarts. Pairs with the VMAP and SCTE-35 fixtures, which describe the same break from the ad-signalling side.
- mpdDASH — Static MPD With a Segment TemplateA DASH manifest with separate video and audio adaptation sets, three video representations, and $RepresentationID$/$Number$ segment-template addressing — the standard VOD packaging shape. Served inline as application/dash+xml with permissive CORS, so dash.js can load it cross-origin. A manifest-parsing fixture: it describes segment URLs rather than shipping the segments.
- m4sDASH VOD — Init Segment (init-stream0.m4s)A DASH initialisation segment carrying codec configuration for one representation. Named by the manifest's $RepresentationID$ template, so this file also exercises whether a client resolves template variables correctly rather than pattern-matching filenames.
Generated by generation/video_timedtext.py. Free for any use, no attribution required — license.