StreamTest

DASH validator

Validate an MPD, including the live timing problems that only show up in the field.

Where to run the fetch
Request headers

For signed URLs and protected origins. In this browser mode, User-Agent, Referer and Cookie cannot be set — browsers forbid it — so use server mode for those.

Fetch through a proxy so the origin never sees our server — and to reach IP-restricted playlists. host:port or http://user:pass@host:port (http proxies).

For DRM streams with a cleartext key. Format kid:key or a 32-character hex key. Used only to play the stream in your browser — the key never leaves this page.

No analysis yet.

Enter a dash manifest url above, or paste the content, to see results here.

What this checks

  • UTCTiming presence — the usual cause of live DASH that stalls on some devices
  • Clock drift between availabilityStartTime and the origin’s own Date header
  • Segment addressing: SegmentTemplate, SegmentTimeline, SegmentBase and BaseURL
  • Adaptation set integrity: codec families, alignment and bitrate ordering
  • DRM: Widevine, PlayReady, FairPlay and ClearKey signalling, and inline PSSH

How to read the results

  • UTCTiming first. A live MPD without it is the most common cause of a stream that plays for you and stalls for other people.
  • Compare availabilityStartTime against the origin Date header shown on the page: an anchor in the future means no segment is available yet.
  • Then read the addressing. SegmentTemplate, SegmentTimeline and SegmentBase fail in different ways, and the validator names which one your manifest uses.
  • Treat DRM findings as signalling checks: a missing PSSH breaks playback even when the licence server is perfectly healthy.

What it does not do

  • It validates the manifest, not the media. Segments that 404 or carry the wrong codec still appear under a manifest that parses.
  • Licence acquisition is never attempted. ClearKey keys you supply are used only for the in-browser preview.
  • Multi-period manifests are checked period by period; continuity of encoder timelines across periods is out of scope.

Privacy

Results are never shared. Choose “This browser” and the fetch and the analysis both happen on your machine — the URL, any headers you set and the results never reach our servers, which is also how you test a stream on a private network or behind a login. Pasted content is always analysed locally.

Common DASH findings, explained

Every finding links to a write-up on what it means and how to fix it.

Frequently asked questions

What does the DASH validator check?
Manifest well-formedness, UTCTiming, availabilityStartTime against the origin clock, segment addressing, adaptation-set integrity, and DRM signalling for Widevine, PlayReady, FairPlay and ClearKey.
Why does my live DASH stream stall only on some devices?
Usually the clock. Without UTCTiming a player trusts the device clock, so a viewer whose clock is minutes out asks for segments that do not exist yet.
Can it validate an encrypted manifest?
Yes. ContentProtection signalling and inline PSSH are read and reported. For the preview you can supply cleartext ClearKey keys; other systems are reported, not decrypted.
Does it check SegmentTimeline gaps?
Yes. Timeline entries are walked in order, and gaps or overlaps between S elements are reported with the period they fall in.
What if the manifest is behind authentication?
Set Authorization, Cookie or custom headers for the test, or run it in your browser so the fetch happens from your own machine.