DASH (Dynamic Adaptive Streaming over HTTP)

DASH stands for Dynamic Adaptive Streaming over HTTP, usually written MPEG-DASH. It is a form of Adaptive bitrate streaming over plain HTTP, standardised as ISO/IEC 23009-1. A packager cuts an encode into short segments and writes an XML manifest, the Media Presentation Description (MPD). The MPD lists every quality level and where its segments live. The player reads the MPD and fetches segments over ordinary HTTP, so each viewer gets the best quality their connection can sustain. DASH is the vendor-neutral counterpart to Apple’s HLS. DASH is an international standard “not owned by any single company”. It is a delivery format and nothing more: not a codec (DASH is codec-agnostic), not a DRM system, not a transport protocol, and not a server product. MPEG describes it as streaming “using existing available HTTP infrastructure (particularly servers and CDNs, but also proxies, caches, etc.)”. That is the whole point: a CDN can carry DASH with no media-specific feature at all.

How it works

DASH defines exactly two artefacts: the MPD, and the segments it points at. ISO ratified MPEG-DASH in April 2012. The current freely available text is the 5th edition, ISO/IEC 23009-1:2022. ISO has since published the 6th-edition schema insert. That insert is for the edition that replaces the 2022 text.

1. Package. An encoder and packager emit the segments plus the MPD that describes them. In practice the segments are fragmented MP4 (fMP4). That is convention rather than the format: DASH “has specific provisions for the MPEG-4 file format and MPEG-2 Transport Streams, but can be used with any media format”. Akamai states the practice plainly: DASH, “although allowing TS, almost uniformly uses ISO Base Media File Format (ISOBMFF) in practice”.
2. Describe. The MPD is a four-level hierarchy. The MPD root carries one or more Periods. A Period carries AdaptationSets (alongside EventStreams, BaseURLs and ContentProtection). An AdaptationSet carries Representations, the individual quality levels. Each Representation’s segments are addressed by SegmentBase, SegmentList (an explicit list of SegmentURL elements) or SegmentTemplate (a URL pattern with $Number$ or $Time$ substituted per segment).
3. Choose. The player fetches the MPD first. It then selects one Representation per AdaptationSet, based on available bandwidth, viewport size, codec support and language.
4. Adapt. Adaptation is a client decision, not a server one. As Cloudflare puts it, “your player contains adaptive bitrate logic to estimate the viewer's available bandwidth, and select the optimal resolution to play”. Switching cleanly needs aligned switch points. That is a profile requirement rather than an inherent property of DASH. The DASH-IF interoperability guidelines require that “segments are keyframe-aligned across representations, start with a random access point, and do not vary too dramatically in duration”. This means “players can switch easily between representations without having to download overlapping segments”.
5. Refresh, for live. A live MPD sets the type attribute to dynamic (it is static for on-demand) and advertises a minimumUpdatePeriod. The player refetches the MPD on that cadence to discover new segments. The 5th edition added “MPD patching to support explicit MPD updates”. So a client can fetch a small diff instead of the whole manifest.
6. Package once, serve both. With CMAF (ISO/IEC 23000-19), one set of fMP4 segments feeds both DASH and HLS. Without it, as Akamai notes, “to reach an HLS and DASH audience, content distributors must encode and store the same audio and video data twice”.

Why it matters for a CDN

DASH was designed around HTTP. It deliberately rides the servers, proxies and caches that already make up the web. For a CDN it is two very different kinds of object, plus a handful of delivery hooks:

• Segments are static, immutable objects. A segment never changes once written. So it takes a long TTL, and a popular stream converges on a very high cache hit ratio. This is the bulk of the bytes.
• The MPD is small and mutable. It changes rarely for on-demand and constantly for live. So it needs a short TTL, and it is the one object whose staleness breaks playback outright.
• One manifest can span several CDNs. The MPD may carry repeated BaseURL elements. This gives “support for multiple CDNs/caches with the same manifest … thus improving scalability and fault tolerance” without a second manifest. Repeated BaseURLs are the oldest and simplest multi-CDN mechanism in streaming.
• Newer editions steer clients actively. The 6th-edition schema adds a ContentSteering element (with defaultServiceLocation and queryBeforeStart attributes). This element points the player at a steering server that can move it between CDNs mid-session. The schema also adds CMCDParameters. This lets the MPD itself tell the player to report Common Media Client Data to the edge. Neither element exists in the 5th-edition schema.
• Segments need not be separate files. DASH allows “non-segmented origin files — files can optionally be stored contiguously on the server and the segments accessed via byte-range requests”. So origin and edge must honour HTTP Range.
• One encryption, many DRMs. DASH supports Common Encryption. This is “one-time encryption and packaging of content allowing simultaneous use of multiple DRM technologies”. So a single cached copy serves Widevine, PlayReady and other clients.
• It is the non-Apple half of the device matrix. Apple documents HLS as its own delivery route for iPhone, iPad, Apple TV and macOS. On the other side, Android’s ExoPlayer “supports DASH with multiple container formats”. That split, not any technical merit, is why most services publish both.

What CDNs do

• AWS CloudFront delivers media you have already packaged, from any HTTP origin. Its documentation names MPEG DASH, Apple HLS, Microsoft Smooth Streaming and CMAF as the common package formats.
• Akamai Adaptive Media Delivery lists Dynamic Adaptive Streaming over HTTP (MPEG-DASH) and CMAF among the formats it delivers. DASH needs no opt-in. It is CMAF that does: “CMAF support requires that you package your media as CMAF and select HLS, DASH, or both when defining Content Characteristics in your AMD property”. For low-latency DASH, Akamai recommends its own Media Services Live as the origin. Akamai also states that HDS and Smooth are not supported at all in low-latency mode.
• Cloudflare Stream gives every video and live input its own HLS and DASH manifest by default. It is “compatible with all video players that support HLS and DASH”.

Watch out for

• Over-caching a live MPD. A stale manifest stalls or breaks playback. Cloudflare’s guidance for Stream is blunt: “manifests are dynamic assets that may be updated at any time. Do not cache, proxy, or store manifests; always read them directly from Stream. Outdated manifests may be missing features or refer to assets which have been moved.” Treat any live MPD the same way.
• Shattered segment cache keys. Template-generated URLs are the reason DASH caches well. DASH-IF calls them “templated manifests … compact manifest for fast start-up, as well as avoiding manifest download with every segment”. Bolt a per-session query string or token onto those URLs, and you fragment one hot object into one object per viewer.
• Cross-origin fetches need CORS. Browser DASH players fetch the MPD and segments with JavaScript. So when media and page are on different origins, the normal CDN case, every DASH resource must be delivered with CORS headers permitting GET. Player vendors are explicit that this “is not a specific requirement to Radiant Media Player but to any player streaming content to a HTML5 video player making cross-domain requests with JavaScript”. Same-origin delivery needs nothing.
• Range support is not optional if you use it. Contiguous single-file DASH is served entirely by HTTP Range. So origin and edge must handle range requests and serve the initialization segment.
• Player gaps are real, and they are not the CDN’s fault. ExoPlayer, for example, will not play MPEG-TS inside DASH at all (“no support planned”). It also does not implement server-guided xlink ad insertion, even though both are legal DASH. Validate against the players you actually ship.
• Multi-period content and ad insertion depend on manifest freshness. DASH offers “efficient ad insertion — server-based and client-based targeted ad-insertion through the use of periods”. This means an edge that caches the MPD too long can silently break server-side ad insertion.
• Low latency changes the delivery contract. LL-DASH uses CMAF chunks: “multiple ‘moof’ and ‘mdat’ boxes, allowing the client to access the media data before the segment is completely finished”. This requires that “the server must support HTTP 1.1 chunked transfer encoding” end to end, and that the MPD carry availabilityTimeComplete and availabilityTimeOffset. It also breaks naive client bandwidth estimation, because “the download time of a segment is often times similar to the segment duration”. A proxy that buffers whole objects destroys the benefit.
• Do not conflate the HTTP streaming formats. Microsoft Smooth Streaming and Adobe HDS are separate delivery formats that also ride HTTP. Akamai still lists HDS, but only for the long-dead Adobe Flash and AIR runtimes.

Best practice

• Cache segments with long, effectively immutable TTLs. Give on-demand MPDs a moderate TTL and live MPDs a very short one, aligned with the manifest’s own minimumUpdatePeriod.
• Package once as CMAF. Emit both a DASH manifest and an HLS playlist, rather than maintaining two encodes and paying twice for storage and edge cache space.
• Keep segment URLs template-generated and free of per-session parameters; carry session state in cookies, headers or the manifest instead of the cache key.
• Serve manifests and segments with CORS headers permitting GET whenever the player page is on another origin. Also honour HTTP Range on both origin and edge.
• For multi-CDN, list several BaseURL elements for static failover. Adopt the 6th-edition ContentSteering element when your players support it, for genuine mid-session steering.
• Before enabling low-latency DASH, verify chunked transfer encoding survives every hop from packager to player: origin, shield and edge.