How to Validate HLS and DASH Streams

When an adaptive stream fails to play, the cause is usually one of two things: the manifest describes something a player cannot follow, or the manifest is fine and the segments it points at are not actually there. These need different fixes, and telling them apart quickly is most of the work.

This guide covers loading a stream in Video Commander, reading the manifest, running the validator, and probing segments to isolate which of the two you are dealing with.

Loading a Stream

Paste an HLS playlist or DASH manifest URL into the address bar and load it, or open a local .m3u8 or .mpd file. Video Commander detects the format and opens it as a source tab, the same way it handles an MP4.

Local files work as well as remote ones, which is useful for checking packager output before it reaches a CDN.

The Inspect view then gives you two tabs that matter here: Manifest for reading what the stream declares, and Validator for checking whether those declarations are correct.

Reading the Manifest

The Manifest tab parses the stream and shows a format badge (MPEG-DASH or HLS) alongside a refresh control. For a DASH manifest it breaks down into Overview, Periods and Tracks, Representations, XML, and Raw.

Periods and Tracks is where you check the shape of the ladder. Each period lists its adaptation sets with type, language, role, MIME type, and max resolution, and each set expands into its representations with codec profile and level, resolution, and bitrate.

This is the fastest way to confirm a ladder is what you intended: that the rungs step sensibly in bitrate, that codec profiles match what your target devices support, and that audio is present in the languages you expect. The XML and Raw tabs are there when you need to read the source document rather than the parsed view.

Running the Validator

The Validator tab runs conformance checks against the loaded stream and reports what it finds.

The left panel shows the parsed Structure, navigable down to individual segments. The right panel lists Findings, with counts at the top and each finding grouped by severity:

• Error: the stream violates the specification. Expect playback failures.
• Warning: legal but likely to cause problems on some players or in some conditions.
• Info: worth knowing, not a defect.

Each finding carries a stable code, a plain-language message, and the node it applies to. Selecting a finding highlights the relevant node in the structure tree, so you can go from a message to the exact segment or representation it came from.

Some representative HLS findings:

• HLS_006 Segment #2 duration 8.500s exceeds TARGETDURATION 6s. A real spec violation. EXT-X-TARGETDURATION must be greater than or equal to every segment duration, and players size their buffers from it.
• HLS_007 EXT-X-VERSION is 2 (recommend >= 3). Version 2 predates floating point durations, so integer rounding of segment durations can accumulate drift.
• HLS_009 Playlist contains EXT-X-DISCONTINUITY but EXT-X-DISCONTINUITY-SEQUENCE is absent or zero. Common after ad insertion or a mid-stream encoder change, and a frequent cause of players losing timeline sync.
• HLS_008 EXT-X-PLAYLIST-TYPE not set; live stream assumed. Informational, but if this is meant to be a VOD asset the missing tag will change how players treat seeking.

Use Refresh to re-run the checks after fixing your packager output, without reloading the tab.

Probing Segments

A manifest can pass every conformance check and still fail to play, because conformance says nothing about whether the segments are actually reachable. Probe URLs resolves the addressable segments and fetches them.

Probe results appear under the findings, showing how many were sampled and how many failed. A failure looks like this:

PROBE RESULTS   1 sampled · 1 unreachable
seg0.ts         No such file or directory...

That is a delivery problem, not a manifest problem. The playlist is describing a segment that does not exist at the path it advertises, which typically means a packager wrote a relative path that does not match the deployed directory layout, or an upload did not complete.

Probing also reports what it found inside each segment it could fetch: codec, container, duration, and any detected anomalies. Selecting a single segment, media playlist, or representation probes just that resource, or you can probe across all addressable segments in one action. Sampling a few segments is usually enough for a first pass; probe everything when you suspect a specific range is missing.

A Triage Order That Works

1. Check for errors first. Anything in the Error group will break playback somewhere. Fix these before interpreting anything else.
2. Probe the segments. If segments are unreachable, stop and fix delivery. Warnings about the manifest do not matter while the media is missing.
3. Read the warnings. With errors cleared and segments reachable, warnings explain device-specific and intermittent failures: the stream that plays in one player and stalls in another.
4. Compare against the ladder. Open the Manifest tab and confirm the representations match what you intended to publish. A stream can be perfectly valid and still be the wrong stream.
5. Play it. The Player tab plays HLS and DASH with a debug overlay for buffering state, dropped frames, current bitrate, and resolution, plus quality and bandwidth selectors for exercising adaptive switching. A clean validator report and a stream that visibly fails to switch rungs are both useful signals.

The Short Version

• Ladder shape, codecs, languages: Inspect → Manifest → Periods and Tracks
• Conformance checks by severity: Inspect → Validator
• Jump from a finding to its node: select the finding
• Are the segments actually there: Probe URLs
• Re-run after a packager fix: Refresh
• Watch adaptive switching behave: Player tab