CMAF explained: what the Common Media Application Format is, how it relates to HLS and DASH, why low-latency streaming converged around chunked CMAF, CMAF ingest replacing RTMP for broadcast, and what CMAF means for surveillance VMS deployments.
The streaming industry has spent the last decade running parallel ecosystems that did the same job slightly differently and required twice the engineering. HLS for Apple and most live broadcasters. MPEG-DASH for Google and most premium video-on-demand platforms. Two manifests. Two segment formats. Two encoding passes. Two CDN configurations. The cost of running both was real, and the cost of choosing one was missing the other ecosystem.
CMAF, the Common Media Application Format, is the standard the industry built to end the duplication. The format is ISO/IEC 23000-19, originally published in 2018 and progressively adopted across the streaming stack since then. By 2026, CMAF is the de facto interoperability layer for HLS and MPEG-DASH segmented streaming, the foundation underneath Low-Latency HLS (LL-HLS) and Low-Latency DASH (LL-DASH), and an increasingly common ingest format for premium broadcast workflows.
This guide explains what CMAF actually is, how it relates to HLS and DASH, why low-latency streaming converged around it, what CMAF means specifically for surveillance and security operations, how CMAF ingest is changing the relationship between encoders and streaming servers, and how modern video management software handles CMAF alongside the other streaming formats a serious deployment needs.
CMAF is a media container format for delivering segmented video over HTTP. The format is built on ISO Base Media File Format (the same container family that produces MP4 files) and specifies how video, audio, and subtitle data is packaged into short fragments that streaming servers can deliver and players can consume.
The defining characteristic of CMAF is that the same fragments work for HLS and for MPEG-DASH. Before CMAF, an encoder produced one set of segments for HLS (typically MPEG-2 Transport Stream files) and a separate set of segments for DASH (typically fragmented MP4 files). The two sets were not interchangeable. A streaming platform that wanted to support both ecosystems had to run two parallel encoding pipelines, two storage layers, and two CDN delivery paths.
With CMAF, the same fragments serve both HLS and DASH. The platform encodes once, stores once, and delivers through one CDN configuration. The HLS manifest references the CMAF fragments. The DASH manifest references the same CMAF fragments. The cost of supporting both ecosystems drops to roughly the cost of supporting one.
CMAF does not replace HLS or DASH. It sits underneath both. HLS and DASH remain the delivery protocols. The .m3u8 and .mpd manifests are still produced. The streaming logic on the player side is unchanged. CMAF changes what is inside the segments, not how the segments are addressed or delivered. This is the most important architectural fact about CMAF and the one most articles understate: CMAF is interoperability infrastructure, not a new streaming protocol.
The streaming industry standardized on segmented delivery (HLS and DASH) in the early 2010s because segmented delivery solved real problems. Variable bandwidth players could adapt by switching segments at different quality tiers. Standard HTTP infrastructure (CDNs, caches, firewalls) could deliver video without specialized streaming servers. The architecture scaled to millions of concurrent viewers at marginal cost.
The cost of the segmented architecture was duplication. Apple's HLS used MPEG-2 Transport Stream segments. Google and the MPEG community's DASH used fragmented MP4 segments. The two formats were technically different enough that the same encoder could not produce both without running two pipelines, and the same CDN could not serve both without storing two copies. Platforms that wanted to support Apple devices and non-Apple devices spent meaningful engineering and operational cost on duplication.
CMAF was proposed in 2016 by Apple and Microsoft as a joint specification to end the duplication. The standard was finalized as ISO/IEC 23000-19 in 2018, and Apple's HLS specification was updated to formally support CMAF segments alongside the legacy Transport Stream segments. By the early 2020s, the major encoders, CDNs, and player libraries had added CMAF support. By 2026, CMAF is the default segmented format for new streaming deployments, with legacy Transport Stream HLS maintained only for backward compatibility with older Apple devices.
The story matters because the same convergence logic is now driving low-latency streaming. Both LL-HLS (Apple's low-latency extension to HLS) and LL-DASH (the low-latency profile of MPEG-DASH) build on CMAF as the common substrate. The duplication problem that CMAF solved for general segmented streaming is the same duplication problem it now solves for low-latency segmented streaming.
The relationship is layered. HLS and DASH are the delivery protocols, defined by manifests (.m3u8 for HLS, .mpd for DASH) that describe how segments are organized into playable streams. CMAF is the segment format, defining the binary structure inside each segment file.
In a CMAF-based HLS deployment, the .m3u8 manifest references CMAF segment files. The player downloads the manifest, parses it, and downloads the CMAF segments in sequence. The HLS protocol behavior is unchanged. The segments inside are CMAF fragments instead of legacy Transport Stream files.
In a CMAF-based DASH deployment, the .mpd manifest references the same CMAF segment files. The player downloads the manifest, parses it, and downloads the CMAF segments. The DASH protocol behavior is unchanged. The fragmented MP4 segments that DASH already used are technically very close to CMAF fragments, which is why DASH adopted CMAF earlier and more completely than HLS did.
The dual-manifest pattern is what produces the interoperability benefit. A single set of CMAF segments on the CDN can be served to HLS players through the HLS manifest and to DASH players through the DASH manifest. The CDN stores one copy. The encoder produces one copy. The operational cost drops meaningfully.
For Visylix and other VMS platforms that need to deliver to mixed-protocol consumers (browsers expecting HLS, broadcast partners expecting DASH, mobile apps expecting HLS), the dual-manifest CMAF pattern is the architecture that minimizes the operational cost of supporting all of them.
The most operationally important reason buyers care about CMAF in 2026 is low-latency streaming. CMAF fragments can be subdivided into smaller pieces called chunks, and the chunked CMAF pattern is the substrate that LL-HLS and LL-DASH use to deliver streaming latency below 5 seconds.
Standard HLS delivers 6 to 30 seconds of glass-to-glass latency because the player has to wait for full segments (typically 2 to 10 seconds each) to be available before it can start downloading them. Chunked CMAF lets the encoder publish partial fragments while a segment is still being produced, and the player can start downloading those partial chunks before the full segment is complete. The effective latency drops to 2 to 5 seconds.
This matters for surveillance because the protocols that buyers actually shortlist for live monitoring (WebRTC for sub-second, LL-HLS for 2 to 5 seconds, standard HLS for multi-second dashboard tiling) all benefit from CMAF as the underlying format. WebRTC is the only protocol that delivers true sub-second surveillance latency, but for the workflows where 2 to 5 seconds is acceptable, LL-HLS over CMAF is meaningfully cheaper to operate than WebRTC at scale.
The Visylix HLS vs WebRTC guide covers the surveillance-specific tradeoffs between the two latency tiers in detail. The short version is that CMAF makes the LL-HLS option meaningfully more practical than it was in the legacy Transport Stream era, which is why LL-HLS is increasingly the dashboard-and-public-distribution protocol of choice in 2026 surveillance deployments.
Buyers asking CMAF vs HLS are usually asking the wrong question, because CMAF is not an alternative to HLS. CMAF is a segment format that HLS can use. The right comparison is between legacy HLS (with Transport Stream segments) and modern HLS (with CMAF segments).
Legacy HLS. MPEG-2 Transport Stream segments. Universal Apple device compatibility back to early iOS versions. The standard for HLS deployments before 2018 and the current pattern for deployments that need broad legacy device support. Larger segment file overhead than CMAF (Transport Stream has a constant per-packet header tax that CMAF does not).
Modern HLS with CMAF. CMAF segments. Equivalent compatibility on modern Apple devices (iOS 10+, macOS 10.12+) and full compatibility with DASH players through dual-manifest delivery. Lower file overhead. Compatible with chunked delivery for LL-HLS. The pattern that consistently makes sense for new deployments in 2026 unless the buyer has specific legacy device support requirements that force Transport Stream.
For surveillance deployments specifically, the question is which segment format the VMS produces by default and whether it can serve mixed-protocol consumers from the same segments. A VMS that produces only legacy Transport Stream segments forces the buyer to operate parallel encoding for any DASH consumers. A VMS that produces CMAF segments and serves both HLS and DASH manifests from the same segments minimizes the operational cost of supporting mixed consumer types.
The same misframe applies to CMAF vs DASH. CMAF is the segment format. DASH is the delivery protocol. DASH has used fragmented MP4 segments since its inception, and the fragmented MP4 format that DASH used is technically very similar to CMAF. The transition from DASH-specific fragmented MP4 to CMAF was less of a change than the HLS transition from Transport Stream to CMAF.
In practice, modern DASH deployments use CMAF segments. The .mpd manifest still describes the DASH delivery profile. The fragments inside are CMAF. DASH and HLS converged on CMAF as the common segment format, which is the entire point of CMAF.
The 2026 trend that is materially changing how live broadcasting works is CMAF ingest. The pattern works as follows.
Traditional broadcasting ingest uses RTMP. The encoder pushes an RTMP stream to a streaming server. The streaming server transcodes the RTMP stream into segmented formats (CMAF, HLS, DASH) for delivery to viewers. RTMP is reliable, universally supported by encoders, and operationally simple, but it adds the encoding-transcoding pipeline as a step in the workflow.
CMAF ingest skips the transcoding step. The encoder produces CMAF segments directly and pushes them to the streaming server using HTTP. The server stores the segments and references them from HLS and DASH manifests for delivery. The pattern is meaningfully more efficient because the segments produced by the encoder are the same segments delivered to viewers. There is no transcoding step in the middle.
CMAF ingest is increasingly the pattern that premium broadcasters use (sports, news, live entertainment) where the operational cost of the RTMP-to-CMAF transcoding step is meaningful at scale. Adoption is still partial in mid-2026, with broad encoder support but uneven CDN and streaming server support. The standardized signaling protocol for CMAF ingest is being finalized, and the operational pattern is consolidating around it.
For surveillance, CMAF ingest is largely a future story rather than a current operational requirement. Most surveillance ingest is still RTSP (from cameras), RTMP (from encoders and mobile apps), or WebRTC (with WHIP signaling). CMAF ingest is appropriate for surveillance deployments that are also pushing live streams to broadcast destinations where CMAF ingest is the destination's preferred protocol, which is a small but growing set of use cases.
The surveillance industry adopted segmented HLS streaming for browser-based viewing and dashboard distribution in the late 2010s. Most surveillance VMS platforms produce HLS streams using either Transport Stream segments (legacy) or CMAF segments (modern). The difference matters for three specific surveillance workflows.
Browser-based live viewing. The CMAF-based HLS pattern delivers slightly lower file overhead, slightly more efficient CDN caching, and full compatibility with the LL-HLS workflow that delivers 2 to 5 seconds of viewing latency. For dashboard tiling and multi-camera situational awareness in browser interfaces, CMAF-backed HLS is the architecture that consistently works.
Public-facing distribution. Smart city deployments, transit authorities, and public-safety operations that publish camera streams to citizen apps, public dashboards, or transit displays benefit from CMAF-backed delivery because the same segments serve both HLS-preferring clients (iOS devices, Apple TV, Safari) and DASH-preferring clients (Android, smart TVs, embedded devices) without duplication.
Integration with broadcast workflows. Surveillance operations that occasionally push live footage to broadcast destinations (live news coverage of a public-safety incident, public-information broadcasts during emergencies) benefit from the CMAF ecosystem because broadcast partners increasingly accept CMAF-based delivery as the modern ingest pattern.
For most surveillance deployments most of the time, CMAF is operationally invisible. The VMS produces CMAF segments. The browser plays them as HLS. The integration with downstream consumers works through whatever protocol they prefer. The buyer does not need to think about CMAF directly. The buyer only needs to verify that the VMS supports CMAF segments natively, which any serious enterprise VMS in 2026 should.
The honest 2026 status of CMAF adoption across the streaming ecosystem runs approximately as follows.
Encoders. Universal support among modern professional encoders (FFmpeg, Bento4, AWS Elemental, Wowza Streaming Engine, Visylix, and the major hardware encoders from Teradek, AJA, Matrox, Blackmagic, Elgato). Legacy encoders that have not been updated since 2018 may produce only Transport Stream segments. The adoption gap is closing as legacy encoders are replaced.
CDNs. Universal support among major CDNs (Akamai, Fastly, CloudFront, Cloudflare, Bunny, Verizon Edgecast). CMAF segments deliver through the same HTTP infrastructure as any segmented streaming and require no special CDN configuration.
Streaming servers. Universal support among modern streaming servers (Wowza, Nimble Streamer, MediaMTX, Visylix, Red5 Pro, Ant Media). Legacy servers that have not been updated since 2018 may not support CMAF natively. The transition is largely complete in the commercial server market.
Player libraries. Universal support in modern HLS and DASH players (hls.js, dash.js, Shaka Player, Video.js, Apple's native HLS player on iOS 10+, ExoPlayer on Android, the major OTT TV player libraries). The transition is largely complete.
Browser support. Native HLS playback in Safari and on iOS handles CMAF segments transparently. Other browsers play CMAF-based HLS through hls.js and CMAF-based DASH through dash.js or Shaka Player. The transition is largely complete.
The implication is that buyers can deploy CMAF-based segmented streaming today without compatibility concerns across the modern streaming stack. The only buyers who should not deploy CMAF are buyers with specific legacy device support requirements that force them to maintain Transport Stream HLS, which is an increasingly narrow set of cases.
Visylix is built around a native streaming engine that supports all 10 major streaming protocols natively, including RTSP, RTMP and RTMPS, HLS and LL-HLS (with CMAF segments by default), WebRTC (with WHEP and WHIP signaling), SRT, ONVIF, GB28181, NDI, and RIST. The same camera or stream can be ingested through any of these protocols and delivered through any other, with server-side transcoding that decouples ingest from delivery.
For CMAF specifically, Visylix produces CMAF segments by default for HLS and LL-HLS delivery, supports dual-manifest delivery to serve both HLS and DASH consumers from the same segments, and integrates with the modern CMAF ingest pattern for broadcast workflows that prefer CMAF over RTMP. The 12 self-learning AI models in Visylix operate on the source video regardless of which delivery format the consumers prefer, which means a stream delivered as CMAF-backed HLS receives the same face recognition, ANPR, object detection, person tracking, crowd detection, PPE detection, pose estimation, heat map analytics, motion detection, unique person counting, intrusion detection, and line crossing detection as a stream delivered through any other protocol.
For Indian deployments, Visylix operates natively in 13 Indian languages, supports INR pricing through Razorpay, and runs on customer infrastructure rather than foreign cloud, which matters for data sovereignty considerations under the DPDP Act and for predictable bandwidth economics inside Indian site networks.
If you are designing a streaming deployment that needs to deliver to mixed-protocol consumers (HLS browsers, DASH players, broadcast partners), running into the operational cost of parallel HLS and DASH encoding, or evaluating LL-HLS for surveillance workflows where 2 to 5 seconds of latency is the right tradeoff, the Visylix team would welcome a conversation about how to design the CMAF-based architecture for the specific deployment. Reach us at https://visylix.com/contact.
CMAF (Common Media Application Format) is a media container format for delivering segmented video over HTTP, standardized as ISO/IEC 23000-19 and adopted across the streaming industry to end the duplication between HLS and MPEG-DASH ecosystems. CMAF is not a streaming protocol. It is the segment format that HLS and DASH both use, which means the same CMAF segments can be delivered to HLS players and DASH players from the same CDN configuration with one encoding pass. CMAF is the substrate that LL-HLS and LL-DASH use to deliver 2 to 5 seconds of low-latency streaming, which is the latency tier between standard HLS (6 to 30 seconds) and WebRTC (200 to 500 milliseconds). CMAF ingest is the modern pattern that is replacing RTMP for premium broadcast workflows, with broad encoder support and growing streaming server support in 2026. For surveillance deployments, CMAF is the right segment format for browser-based live viewing, public-facing distribution, and integration with broadcast workflows. CMAF adoption is essentially complete across modern encoders, CDNs, streaming servers, and player libraries, with the only remaining holdouts being deployments with specific legacy device support requirements. The right question for a VMS vendor is not does it support CMAF (the answer should be yes by default) but how does it use CMAF specifically for the workflows the buyer needs.
CMAF (Common Media Application Format) is a media container format for delivering segmented video over HTTP. The format is built on ISO Base Media File Format (the same container family that produces MP4 files) and specifies how video, audio, and subtitle data is packaged into short fragments for streaming. CMAF was standardized as ISO/IEC 23000-19 in 2018 to provide a common segment format that both HLS and MPEG-DASH could use, ending the previous duplication where HLS used MPEG-2 Transport Stream segments and DASH used fragmented MP4 segments. By 2026, CMAF is the de facto segmented format for modern streaming deployments.
CMAF stands for Common Media Application Format. The name reflects the standard's purpose: a common (meaning shared between HLS and DASH ecosystems) media (video, audio, subtitles) application format (the container structure that streaming applications consume). The standard is published as ISO/IEC 23000-19 and is part of the broader MPEG-A family of multimedia application format standards.
CMAF and HLS are not alternatives. HLS is a delivery protocol with an .m3u8 manifest that describes how segments are organized into playable streams. CMAF is a segment format that defines the binary structure inside each segment file. Modern HLS uses CMAF segments. The right comparison is between legacy HLS (with MPEG-2 Transport Stream segments) and modern HLS (with CMAF segments). Modern HLS with CMAF is the standard for new deployments in 2026 unless legacy device support forces Transport Stream segments.
CMAF and DASH are also not alternatives. DASH is a delivery protocol with an .mpd manifest. CMAF is a segment format. DASH has used fragmented MP4 segments since its inception, and the fragmented MP4 format is technically very similar to CMAF. Modern DASH deployments use CMAF segments, which is the same convergence that happened for HLS. The result is that one set of CMAF segments on the CDN can be served to HLS players through the HLS manifest and to DASH players through the DASH manifest, eliminating the duplication that previously required two parallel encoding and storage pipelines.
LL-HLS (Low-Latency HLS) is an extension of HLS published by Apple that reduces glass-to-glass latency from the 6 to 30 second range of standard HLS to the 2 to 5 second range. LL-HLS uses chunked CMAF, in which CMAF fragments are subdivided into smaller chunks that the encoder publishes while the segment is still being produced. The player can start downloading those chunks before the full segment is complete, which reduces the buffering latency that standard HLS imposes. LL-HLS is increasingly the protocol of choice for surveillance dashboards and public distribution workflows where 2 to 5 seconds of latency is acceptable and the operational cost of WebRTC at scale is not.
CMAF was created to end the duplication between HLS and MPEG-DASH ecosystems. Before CMAF, an encoder produced one set of segments for HLS (typically MPEG-2 Transport Stream) and a separate set of segments for DASH (typically fragmented MP4). The two were not interchangeable. Streaming platforms that wanted to support both ecosystems had to run two parallel encoding pipelines, two storage layers, and two CDN delivery paths. CMAF was proposed in 2016 by Apple and Microsoft as a joint specification and finalized as ISO/IEC 23000-19 in 2018. The format lets the same segments serve both HLS and DASH players, eliminating the duplication.
CMAF ingest is a streaming workflow pattern where the encoder produces CMAF segments directly and pushes them to the streaming server using HTTP, rather than pushing an RTMP stream that the server then transcodes into CMAF segments. The pattern skips the transcoding step, which makes it meaningfully more efficient at scale. CMAF ingest is increasingly used by premium broadcasters (sports, news, live entertainment) where the operational cost of the RTMP-to-CMAF transcoding step is meaningful. Adoption is partial in mid-2026 with broad encoder support but uneven streaming server support. The standardized signaling protocol for CMAF ingest is consolidating, and the pattern is on track to become the standard premium broadcast ingest by the late 2020s.
This question conflates the segment format with the delivery protocol. CMAF is the segment format. HLS is the delivery protocol. Modern HLS uses CMAF segments. The right comparison is between legacy HLS (with Transport Stream segments) and modern HLS (with CMAF segments). Modern HLS with CMAF is operationally better than legacy HLS for new deployments because the same segments serve both HLS and DASH consumers without duplication, the segment overhead is lower, and the format supports chunked delivery for LL-HLS. The only reason to deploy legacy Transport Stream HLS in 2026 is specific legacy device support requirements.
CMAF itself does not reduce latency compared to fragmented MP4 of equivalent segment length. CMAF reduces latency when combined with the chunked delivery pattern, which both LL-HLS and LL-DASH use. Standard segmented streaming with CMAF segments runs the same 6 to 30 second latency as standard HLS or DASH because the player waits for full segments. Chunked CMAF lets the encoder publish partial fragments while a segment is still being produced and the player can start downloading those chunks immediately, which drops latency to 2 to 5 seconds. The combination of CMAF segments with chunked delivery is the substrate that LL-HLS and LL-DASH use to deliver low-latency streaming.
For surveillance specifically, CMAF is the segment format that the VMS produces when serving live browser-based viewing and public-facing distribution through HLS or DASH. The camera does not produce CMAF directly. The camera produces RTSP or other ingest formats, the VMS transcodes for delivery, and the VMS publishes CMAF segments that browsers and players consume. For workflows where 2 to 5 seconds of latency is acceptable (dashboard tiling, multi-camera situational awareness, public dashboards), CMAF-backed LL-HLS is the protocol that consistently makes operational sense. For sub-second workflows (control room PTZ, AI alert response), WebRTC remains the right answer.