CMAF explained: what the Common Media Application Format is, how it relates to HLS and DASH, why low latency streaming relies on it, and what it means for CCTV.
For a decade the streaming industry ran two parallel systems that did the same job slightly differently. HLS for Apple devices and most live broadcasters. MPEG-DASH for Google and many on demand platforms. Two playlists, two packaging formats, two encoding passes, two delivery setups. Supporting both was expensive; choosing one meant missing the other.
CMAF, the Common Media Application Format, is the standard built to end that duplication. Published as ISO/IEC 23000-19 in 2018 and adopted across the industry since, CMAF is now the shared packaging underneath HLS and MPEG-DASH, the foundation of low latency HLS and DASH, and a growing way for broadcasters to send live video.
This guide explains what CMAF is, how it relates to HLS and DASH, why low latency streaming depends on it, and what it means for video surveillance.
CMAF is a standard way of packaging video into short pieces for streaming over the web. It is based on the same file family as MP4, and it defines how video, audio and subtitles are packed into small fragments that servers deliver and players play.
Its defining feature: the same pieces work for both HLS and MPEG-DASH. Before CMAF, a service produced one set of pieces for HLS and a separate set for DASH, and the two were not interchangeable, so supporting both meant two encoding pipelines, two stores and two delivery paths.
With CMAF, a service encodes once, stores once and delivers once. The HLS playlist and the DASH playlist both point to the same pieces. Supporting both costs roughly what supporting one used to.
CMAF does not replace HLS or DASH. It sits underneath both. The playlists, and the way players fetch video, are unchanged. CMAF changes what is inside the pieces, not how they are found or delivered. It is shared plumbing, not a new streaming protocol.
The industry settled on piece by piece streaming (HLS and DASH) in the early 2010s because it solved real problems. Players could switch quality as bandwidth changed. Ordinary web infrastructure, such as content delivery networks and caches, could deliver video without special streaming servers. And it scaled to millions of viewers cheaply.
The cost was duplication. Apple's HLS packaged video one way (MPEG-2 Transport Stream) and DASH another (fragmented MP4). Services serving both Apple and non Apple devices paid for everything twice.
Apple and Microsoft proposed CMAF jointly in 2016. It was finalised as ISO/IEC 23000-19 in 2018, and Apple updated HLS to support CMAF pieces alongside the old format. Encoders, delivery networks and players followed. Today CMAF is the default for new streaming services, with the old format kept mainly for older devices.
The same logic now drives low latency streaming. Both LL-HLS and LL-DASH are built on CMAF, so the duplication CMAF solved for ordinary streaming, it also solves for low latency streaming.
Think in layers. HLS and DASH are delivery methods, each with a playlist (.m3u8 for HLS, .mpd for DASH) that tells the player which pieces to fetch. CMAF defines what is inside each piece.
In HLS with CMAF, the player reads the HLS playlist and downloads CMAF pieces in order. HLS behaves exactly as before; only the pieces have changed.
In DASH with CMAF, the player reads the DASH playlist and downloads the same CMAF pieces. DASH already used something very close to CMAF, which is why it adopted CMAF earlier and more completely than HLS.
That is the payoff: one set of pieces, two playlists, every player served, with one copy encoded and stored.
The main reason buyers care about CMAF in 2026 is low latency. CMAF pieces can be split into smaller chunks, and chunked CMAF is what LL-HLS and LL-DASH use to cut delay.
Standard HLS is slow because the player must wait for each whole piece to be ready before downloading it. Chunked CMAF lets the encoder publish parts of a piece while it is still being made, and the player starts downloading immediately. The delay falls from many seconds to a few.
For surveillance, this creates three tiers. WebRTC for live response in under a second. LL-HLS for dashboards and overviews where a few seconds is fine. Standard HLS for the widest compatibility. Only WebRTC delivers true sub second viewing, but where a few seconds is acceptable, LL-HLS over CMAF is simple and economical to deliver at scale.
Our HLS vs WebRTC guide covers the surveillance trade offs in detail.
Asking "CMAF or HLS?" is asking the wrong question, because CMAF is something HLS uses. The real comparison is old HLS versus modern HLS.
Old HLS packages video as MPEG-2 Transport Stream. It plays on very old Apple devices and carries more overhead per piece.
Modern HLS packages video as CMAF. It plays on all modern Apple devices, serves DASH players from the same pieces, carries less overhead, and supports chunked delivery for LL-HLS.
For surveillance, the questions are which packaging the video platform uses by default, and whether it can serve different kinds of player efficiently.
The same applies to "CMAF or DASH?" CMAF is packaging; DASH is delivery. DASH always used a format very close to CMAF, so its move to CMAF was a small step. Modern DASH uses CMAF pieces. HLS and DASH converged on CMAF, which was the whole point.
A growing trend in live broadcasting is CMAF ingest.
Traditionally, an encoder sends an RTMP stream to a streaming server, which repackages it into pieces for viewers. RTMP is reliable and universally supported, but it adds a processing step.
With CMAF ingest, the encoder produces CMAF pieces itself and sends them to the server over the web. The pieces the encoder makes are the pieces viewers receive, with no repackaging in between.
Major broadcasters of sports, news and live events increasingly use CMAF ingest. Encoder support is broad, while server and delivery network support is still catching up.
For surveillance, CMAF ingest matters mainly when a security operation also pushes live video to broadcast partners who prefer it. Most surveillance video still arrives over RTSP from cameras, RTMP from encoders and phones, or WebRTC via WHIP.
Surveillance platforms adopted HLS for browser viewing and dashboards in the late 2010s. CMAF matters for three surveillance workflows.
Browser viewing. LL-HLS built on CMAF gives dashboards and multi camera overviews a delay of just a few seconds with very broad compatibility.
Public displays. Smart cities, transit operators and public safety agencies sharing camera views on public dashboards, citizen apps or station screens benefit because the same pieces serve Apple devices and Android, smart TVs and embedded screens.
Broadcast. Operations that occasionally share live footage with broadcasters, for example during an emergency, benefit from the CMAF ecosystem broadcasters increasingly use.
Most of the time, CMAF is invisible. The platform packages the video, the browser plays it, and nobody needs to think about it. What a buyer should check is that the platform supports it properly, and offers WebRTC for the moments when every second counts.
Encoders. Modern professional encoders, from FFmpeg, Bento4, AWS Elemental and Wowza to hardware from Teradek, AJA, Matrox, Blackmagic and Elgato, support CMAF. Very old encoders may not.
Delivery networks. The major content delivery networks, including Akamai, Fastly, CloudFront, Cloudflare and Bunny, deliver CMAF like any other web content, with no special setup.
Streaming servers. Modern streaming servers support CMAF, including Wowza, Nimble Streamer, MediaMTX, Red5 Pro, Ant Media and Visylix.
Players. Modern HLS and DASH players support it: hls.js, dash.js, Shaka Player, Video.js, Apple's built in player and ExoPlayer on Android.
Browsers. Safari and iOS play CMAF based HLS natively; other browsers use hls.js, dash.js or Shaka Player.
In short, you can deploy CMAF today without compatibility worries across modern equipment. Only projects tied to very old devices need the old format.
Visylix is an automated AI video surveillance platform built in India. Its native streaming engine supports 13+ protocols: RTSP, RTMP, HLS, LL-HLS, MPEG-DASH, WebRTC (WHEP and WHIP), SRT and HTTP-FLV, plus GB28181, NDI and RIST ingest and ONVIF camera control. Video arriving over any of them is repackaged for delivery over the others without touching the original picture.
The right format for every job. Visylix builds LL-HLS on CMAF chunks for low latency browser viewing, keeps classic HLS for maximum compatibility, and offers MPEG-DASH output where DASH players need it. For live response, WebRTC delivers live view in under a second, down to under 200 ms.
The same intelligence on every stream. Visylix runs 22 AI analytics built in house, including face recognition, number plate recognition, object detection, person tracking, crowd detection, PPE detection, pose estimation, heat maps, motion detection, unique person counting, intrusion detection and line crossing, on the source video, whatever format viewers receive. Sudarshan automation then decides what matters and acts: alerts, alarm incidents, signed webhooks, MQTT, SIEM and PSIM.
Built for India and the world. An interface in 55 languages including 13 Indian languages, rupee pricing through Razorpay, and deployment on your own infrastructure rather than a foreign cloud, which keeps data under your control and bandwidth inside your own network. Starter and Pro include unlimited cameras on the VMS licence, from ₹4,999 or $49 per month.
Designing a deployment that must serve browsers, public displays and broadcast partners at once? Talk to the Visylix team: https://visylix.com/contact.
CMAF (ISO/IEC 23000-19) is a standard way of packaging video into short pieces for web streaming, created to end the duplication between HLS and MPEG-DASH.
It is not a streaming protocol. It is the packaging both HLS and DASH use, so one set of pieces serves every player.
Delivered in chunks, CMAF powers LL-HLS and LL-DASH, cutting delay to a few seconds. For live response in under a second, use WebRTC.
CMAF ingest is a growing alternative to RTMP for major broadcasters.
For surveillance, CMAF suits browser dashboards, public displays and broadcast sharing. Ask not "does it support CMAF?" but "does it deliver the right format for each job, including WebRTC for live response?"
CMAF (Common Media Application Format) is a standard way of packaging video into short pieces for streaming over the web. It is based on the same file family as MP4 and defines how video, audio and subtitles are packed into small fragments. Standardised as ISO/IEC 23000-19 in 2018, it lets both HLS and MPEG-DASH use the same pieces, ending years of duplication. It is now the default packaging for modern streaming.
Common Media Application Format. "Common" because it is shared between the HLS and DASH worlds; "media" because it carries video, audio and subtitles; "application format" because it is the packaging streaming applications read. It is published as ISO/IEC 23000-19, part of the MPEG-A family of standards.
They are not alternatives. HLS is a delivery method: a playlist (an .m3u8 file) tells the player which pieces of video to fetch, in what order. CMAF defines what is inside each piece. Modern HLS uses CMAF pieces; older HLS uses a format called MPEG-2 Transport Stream. The real comparison is old HLS versus modern HLS.
Also not alternatives. DASH is a delivery method with its own playlist (an .mpd file); CMAF is the packaging inside. DASH always used a format very close to CMAF, so moving to CMAF was a small step. The result: one set of CMAF pieces can serve HLS players and DASH players alike, instead of encoding and storing everything twice.
LL-HLS (Low-Latency HLS) is Apple's extension to HLS that cuts the delay from many seconds to a few. It uses "chunked" CMAF: each piece is split into smaller chunks that are published while the piece is still being made, so the player can start downloading sooner. LL-HLS suits dashboards and public viewing where a few seconds of delay is fine; for live response, WebRTC is faster still.
To end the duplication between HLS and MPEG-DASH. Previously, streaming services had to produce one set of video pieces for HLS and another for DASH, with two encoding pipelines, two stores and two delivery paths. Apple and Microsoft proposed CMAF jointly in 2016, and it was finalised as ISO/IEC 23000-19 in 2018, so the same pieces now serve both.
CMAF ingest means the encoder produces CMAF pieces itself and sends them to the streaming server over the web, instead of sending an RTMP stream the server must repackage. It removes a processing step and is growing among major broadcasters for sports, news and live events. Encoder support is broad; server support is still catching up.
The question mixes up packaging and delivery. CMAF is packaging; HLS is delivery, and modern HLS uses CMAF. Modern HLS with CMAF beats old HLS for new projects: the same pieces serve HLS and DASH players, there is less overhead, and it supports low latency chunked delivery. Old style HLS now makes sense mainly for very old devices.
Not by itself. Standard streaming with CMAF pieces is as slow as standard HLS or DASH, because the player waits for whole pieces. Latency falls when CMAF is delivered in chunks, as LL-HLS and LL-DASH do, letting the player start before a piece is finished. That brings the delay down to a few seconds.
Cameras do not produce CMAF. They send RTSP or similar streams to the video platform, which repackages the video for browser viewing over HLS or LL-HLS, using CMAF pieces for low latency HLS. That suits dashboards, multi camera overviews and public displays where a few seconds of delay is acceptable. For live response, such as steering a PTZ camera or reacting to an AI alert, WebRTC is the right choice: Visylix delivers it in under a second.