Public Test Sources

Verified HLS test streams and M3U8 sample URLs

A known-good HLS stream helps separate a player problem from a source problem. The three public samples below returned HTTP 200 when checked from this project and exercise different parts of an M3U8 player: adaptive variants, alternate audio, subtitles, and a wider bitrate ladder.

Start with the Mux sample for a basic adaptive-bitrate check. Use the Apple sample when you need alternate audio and subtitle declarations, and use the Unified Streaming sample when you want a larger variant set. Each button opens the existing player with the selected URL already populated; the stream still travels directly from your browser to its owner.

These are reference streams, not uptime-monitored production services. An external owner can move, change, rate-limit, or retire a sample at any time. The verification date tells you when this page last received a valid master manifest; it is not a promise that every future request, rendition, segment, subtitle, or device will work.

Checked from the project on July 13, 2026

What was actually verified

We fetched each top-level URL over HTTPS, recorded the HTTP status and response content type, and parsed the returned text with the same manifest parser used by the on-site inspector. All three responses began with #EXTM3U and were classified as master playlists. We also checked declared variants, codecs, audio tracks, subtitles, and resolutions. We did not treat a successful first request as proof that every segment will remain reachable forever.

Three verified HLS sample streams

Basic ABR Test

Mux public HLS sample

This compact master playlist is a practical first check for ordinary H.264 and AAC adaptive playback. Our parser found five variants from 320x184 through 1920x1080, with declared AVC and AAC codec strings. The manifest itself returned HTTP 200 with audio/mpegurl.

https://test-streams.mux.dev/x36xhzz/x36xhzz.m3u8
  • Playlist type: master
  • Detected variants: 5
  • Detected resolution range: 320x184 to 1920x1080
  • Useful for: startup, adaptive-bitrate, quality-menu, and ordinary H.264/AAC tests
Test in player
Tracks And Renditions

Apple Bip Bop 16:9 sample

Apple's Bip Bop example is more useful when you need to inspect media groups as well as video variants. Our parser found six variant entries, two audio entries, and eight subtitle entries. Declared video resolutions run from 416x234 through 1920x1080. The manifest returned HTTP 200 with application/x-mpegURL.

https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_16x9/bipbop_16x9_variant.m3u8
  • Playlist type: master
  • Detected variants: 6
  • Detected media entries: 2 audio and 8 subtitle entries
  • Useful for: audio-group, subtitle-menu, rendition, and Apple HLS compatibility tests
Test in player
Larger Variant Set

Unified Streaming Tears of Steel sample

This Tears of Steel endpoint exposes a broader set of variant declarations than the first sample. Our parser found seven variant entries with AVC and AAC codec strings. The declared resolutions include 224x100, 448x200, 784x350, and 1680x750. The manifest returned HTTP 200 with application/vnd.apple.mpegurl.

https://demo.unified-streaming.com/k8s/features/stable/video/tears-of-steel/tears-of-steel.ism/.m3u8
  • Playlist type: master
  • Detected variants: 7
  • Detected video range: multiple AVC profiles and bitrate choices
  • Useful for: larger quality ladders, manifest parsing, and CDN delivery tests
Test in player

Which sample should you choose?

Test goalStart withReason
Confirm that an HLS player initializesMuxA small master manifest with five common H.264/AAC variants makes the first result easy to interpret.
Test audio or subtitle menusApple Bip BopThe top-level manifest declares alternate audio and subtitle media entries.
Exercise a wider quality ladderUnified StreamingThe checked manifest exposes seven variant entries and several AVC profiles.
Reproduce a customer-specific failureYour authorized streamA public sample proves the player baseline, but only the real delivery chain reproduces its tokens, CORS, codecs, and CDN rules.

A repeatable HLS test workflow

  1. Open one sample in the player and wait for the manifest event before judging video playback.
  2. Check whether the quality selector appears. A populated selector means the master playlist exposed usable variants to the player.
  3. Review the playback diagnostics for manifest, level, media, and error events.
  4. Use the manifest inspector to compare variant count, codecs, tracks, and referenced hosts.
  5. Replace the sample with your own authorized URL without changing the browser, player version, or page.
  6. Compare the first stage that changes. That difference usually points to URL access, CORS, child playlists, segments, encryption keys, or codec support.

What a successful sample test proves

If a public sample loads, the browser can execute the page's player code, create a media pipeline, fetch at least one cross-origin HLS resource, and decode the sample's media on that device. This removes several basic suspects: a completely broken script load, an unsupported browser API, a missing video element, or a general network outage.

It does not prove that your own stream is valid. Your stream can use a different video codec, audio codec, segment container, encryption method, subtitle format, token scheme, hostname, or cross-origin policy. A reference stream is a controlled baseline. Its value comes from keeping the player environment fixed while changing only the source URL.

Why the sample works while your URL fails

A desktop application such as VLC can fetch resources that a webpage is not allowed to read. A browser-based player must obey CORS for the master manifest, child playlists, media segments, initialization segments, subtitles, and encryption keys. One missing response header anywhere in that chain can stop playback after the first manifest succeeds.

Compare the failing request in browser DevTools with the corresponding request from a working sample. Check the response status, final redirected URL, content type, and Access-Control-Allow-Origin header. Do not add a public proxy simply to make the symptom disappear; that changes the delivery path and can hide the problem your real viewers still face.

How to recognize a stale test URL

Public sample lists age quickly. A URL may still appear in search results after its CDN path has been retired or restricted. During this review, a commonly repeated Sintel HLS URL returned HTTP 403, so it was excluded from this page. A useful catalog should prefer a smaller checked set over a larger list with uncertain status.

  • Fetch the exact top-level URL instead of trusting an old screenshot.
  • Require an HLS content type or a response body beginning with #EXTM3U.
  • Resolve and test at least one child playlist for a master manifest.
  • Record the verification date and remove entries that stop serving public test content.
  • Remember that a temporary regional or network failure is not always permanent retirement.

Move from a sample to your own stream

Once a sample works, paste a public or authorized URL from your own environment. Start with the top-level manifest rather than a media segment or a child rendition. If the URL is signed, generate a fresh token and make sure child playlists, segments, subtitles, and key files use compatible authorization rules.

Run the same URL through both playback and inspection. Playback answers whether the complete chain can render video. Inspection answers what the first playlist declares. When inspection succeeds but playback fails, continue downstream to child playlists and segment requests. When inspection fails immediately, focus first on URL validity, redirects, authentication, mixed content, and CORS.

Authoritative sample and protocol sources