VASTlint
Validate

VAST error codes / Linear and media errors

VAST error 402: Media file timeout

Short answer: Fetching the MediaFile took longer than the player allowed.

Debug this tag now

If you only have a live URL, test it first. If the failure is in the wrapper chain, inspect each hop. Validate resolved XML when you already have the response.

Validate this XML →Test this live URL →Inspect this wrapper chain →

What your player reported

402 · Timeout of MediaFile URI.

Wording from the IAB VAST 4.3 specification error table. Players may shorten or reformat it, but the code is the same.

What it means

The player already had an InLine and had chosen a MediaFile. That file did not finish downloading in time. 301 times out on the wrapper URI, before any media file is chosen. 405 means the file arrived and the player still could not display it.

The InLine was fine, and the file was not

402 means the player had already chosen a MediaFile and that URL did not finish downloading in time. The wrapper chain succeeded. The creative was selected. The timeout is the player's, as with 301, and it applies to the media host rather than the ad server.

301 is the wrapper URI. If you see 402, the VASTAdTagURI calls completed. 405 means the bytes arrived and the player still could not display them: a codec, a MIME type that lies, or a delivery mode the player cannot use. 403 means the player never chose a file, because none of the MediaFile elements had a type it supports. A 402 means a choice was made.

Which file it was waiting on

The player picks using type, delivery, bitrate, width, and height. A single 15 Mbps progressive MP4 is a common 402 on a mobile player that would have taken a smaller rendition if one had been listed. bitrate is how the player chooses. A missing bitrate forces a guess, and the guess may be the heavy file.

delivery="streaming" on a URL that is a progressive file, or the reverse, makes the player buffer in the wrong mode and then hit its timer. The file can be reachable in a browser and still 402 inside the player. Check the attributes against the URL, not against a laptop download.

SSAI adds a step. The stitcher may fetch the media on a different timeout from the device. A 402 in a stitched stream can be the stitcher's fetch. The device then plays nothing and the Error URL, if it is fired at all, may be the stitcher's. Look at which host requested the Error URL before you resize the file.

What to change in the tag

Add a smaller progressive rendition beside the large one, with a bitrate the target device can finish. Keep type and delivery honest. If the inspector shows the wrapper URI as the call that hung, you are on 301 and the MediaFile was never requested. Shrinking the mp4 will not move that number.

Common causes

  • The CDN was slow, or the file is larger than the player's wait
  • A single high-bitrate rendition on a device that needed a smaller one
  • delivery="streaming" on a URL that is actually a progressive file the player tried to buffer whole

How to fix it

Check the MediaFile the player selected: type, delivery, bitrate, and the URL. Add a smaller progressive rendition beside the large one. If the wrapper URI is what timed out, the code is 301 and the media file was never requested.

The XML the player was holding

This is the shape that produces error 402. The player then calls the Error URL with [ERRORCODE] set to 402.

<MediaFile delivery="progressive" type="video/mp4" width="1920" height="1080" bitrate="15000">
  <![CDATA[https://cdn.example.com/spot-15mbps.mp4]]>
</MediaFile>

VAST XML fragment only. This excerpt belongs inside a complete VAST document, so standalone validation will fail until it is wrapped in a full <VAST>response.

VAST error codes are runtime buckets emitted by the player. They tell you where the failure happened, not which line of XML caused it. Paste the raw tag into the validator to map this code onto the exact element and rule.

Related vastlint rules

Related error codes

Debug this tag now

Validate the XML, follow the wrapper chain, or check it in CI before launch:

# CLI: exits non-zero on errors, ideal for pipelines
vastlint check creative.xml

Further reading