How long should I actually play a stream before calling it launch-ready?

Several minutes at minimum, not just long enough to see the first frame. Clock drift, buffer exhaustion, and CDN cache staleness on live streams typically surface after the first few segments, not immediately.

Do VOD streams need the live-specific checks on this list?

No. VOD manifests are static, so clock-sync (UTCTiming) and live-edge-advancement checks do not apply. Skip straight from manifest correctness to DRM and player compatibility for VOD content.

What is the most commonly skipped item on this checklist?

Testing on more than one player. A stream that plays fine in the packager vendor's own demo player can still fail on a smart-TV player with a stricter DASH profile requirement or a codec it cannot decode, and that gap only shows up if you test both.

Should I re-test after a CDN configuration change even if the manifest did not change?

Yes. A CDN change can alter Cache-Control behaviour, CORS header pass-through, or Range request support without touching the manifest at all, and any of those three can break playback that looked identical from the origin.

Stream Testing Checklist Before Launch

A stream is ready to launch once you have confirmed four things in order: the entry-point URL is reachable and correctly typed over HTTP, the manifest or playlist itself is structurally correct, live-specific behaviour (clock sync, refresh, live edge) works if the stream is live, and at least one real player has held playback for longer than a single segment. Skipping straight to "it played once" is how streams that pass a five-minute demo fail an hour into public traffic.

This checklist is deliberately format-agnostic where the checks overlap and calls out the HLS/DASH/IPTV-specific items where they diverge. Run it once before every launch and again after any change to the packager, CDN, or DRM configuration, since any of those three can silently break a stream that was fine yesterday.

Delivery and HTTP layer

Confirm the manifest or playlist URL returns 200 (or a redirect you have deliberately accepted) with the correct Content-Type for its format. Confirm Cache-Control on a live manifest is short enough that viewers do not get stuck watching a stale live position; a VOD manifest can and should be cached aggressively instead.

Confirm CORS headers (Access-Control-Allow-Origin, and Access-Control-Allow-Headers if the player sends custom headers) are present on both the manifest and every segment URL if the stream will be played from a web page on a different origin than the media host.

Manifest or playlist correctness

For HLS: confirm #EXT-X-VERSION, #EXT-X-TARGETDURATION, and #EXTINF durations are consistent, and that a master playlist's variants all resolve. For DASH: confirm the MPD is well-formed, type is set correctly, and every addressing scheme (SegmentTemplate/SegmentList/SegmentBase) resolves to real segments. For IPTV: confirm every channel URL in the M3U playlist actually resolves, not just the playlist itself.

Live-specific behaviour

If the stream is live, fetch the manifest or playlist twice several seconds apart and confirm it advances (new segments, incrementing sequence number or timeline) rather than freezing. For DASH, confirm a working UTCTiming element is present and that its time source is not stale-cached. Confirm the live edge holds under sustained playback rather than only at stream start, since clock drift and buffer exhaustion tend to surface only after several minutes.

DRM and content protection, if applicable

If the content is encrypted, confirm the ContentProtection block (DASH) or #EXT-X-KEY tag (HLS) references a key ID that actually matches the encryption used on the segments, and that a real license server round trip succeeds end to end, not just that the manifest declares a DRM scheme. Confirm clear (unencrypted) streams do not accidentally carry leftover ContentProtection or key tags from a previous encode.

Player compatibility

Test on at least one player per target platform family (browser-based dash.js/hls.js/Shaka, a native mobile player, and a set-top or smart-TV player if those are in scope), since codec support and DASH profile support vary meaningfully across them. Confirm the codecs string in the manifest (e.g. avc1.640028, hvc1.1.6.L93.90) matches something every target device can actually decode, not just what the packager defaulted to.

What should trigger a re-run of this checklist?

Any change to the packager, encoder ladder, CDN configuration, DRM key rotation, or origin migration should trigger a full re-run, because any one of those can change segment addressing, caching behaviour, or clock-sync configuration without changing the manifest's surface-level structure. A stream that passed this checklist last month is not evidence it still passes today if any of those pieces moved underneath it.

Step by step

Confirm the manifest or playlist URL returns 200 with the correct Content-Type.
Check Cache-Control is short for live content and CORS headers are present if served cross-origin.
Run format-specific structural checks (HLS tags, DASH MPD schema, or IPTV channel URLs).
For live streams, fetch twice and confirm the manifest or playlist actually advances.
For DASH live, confirm a working UTCTiming source and correct availabilityStartTime.
If encrypted, confirm a real license request succeeds, not just that DRM tags are present.
Play the stream on one representative player per target platform for several minutes, not just a few seconds.
Re-run this checklist after any packager, CDN, DRM, or origin change.

Run it yourself

Free, no sign-up, and every finding links to an explainer.

HLS analyzer →DASH validator →M3U checker →

Frequently asked questions

How long should I actually play a stream before calling it launch-ready?: Several minutes at minimum, not just long enough to see the first frame. Clock drift, buffer exhaustion, and CDN cache staleness on live streams typically surface after the first few segments, not immediately.
Do VOD streams need the live-specific checks on this list?: No. VOD manifests are static, so clock-sync (UTCTiming) and live-edge-advancement checks do not apply. Skip straight from manifest correctness to DRM and player compatibility for VOD content.
What is the most commonly skipped item on this checklist?: Testing on more than one player. A stream that plays fine in the packager vendor's own demo player can still fail on a smart-TV player with a stricter DASH profile requirement or a codec it cannot decode, and that gap only shows up if you test both.
Should I re-test after a CDN configuration change even if the manifest did not change?: Yes. A CDN change can alter Cache-Control behaviour, CORS header pass-through, or Range request support without touching the manifest at all, and any of those three can break playback that looked identical from the origin.