We’ve already covered details of how CMAF and WebRTC deliver streams, but what about a direct comparison of the performance of CMAF vs WebRTC. This post will cover just that.
CMAF vs WebRTC
WebRTC vs CMAF: Transport
CMAF (as an HTTP based protocol) uses the standard HTTP protocol to send media requests between web servers and clients. As a connectionless text based protocol, each request requires opening a separate connection using TCP to transfer requests and then closing it once the request has been serviced.
WebRTC creates a connection through through the RTCPeerConnection which is a more complicated process than HTTP. First, the browsers are connected through signaling, by passing the Session Description Protocol (SDP) and exchanging ICE candidates. Then encryption keys are exchanged using DTLS (Datagram Transport Layer Security). This signaling discovers where the two users are and how to connect. Signaling takes place over an HTTPS connection or a WebSocket (Red5 Pro uses a WebSocket) and is then implemented via JS code. As this process creates a direct connection between two web browsers, it is considered a peer-to-peer connection. This process has been covered in detail in a past article (and a really deep-dive here).
One very important difference is that CMAF (through HTTP) creates a TCP connection while WebRTC is a UDP based connection. This has important consequences in regards to the results they produce, namely when it comes to latency. We will cover that in more detail later on.
CMAF vs WebRTC: Latency
Despite the fact that both CMAF and WebRTC were created with the intention of reducing latency, WebRTC is a new method designed specifically to produce the lowest latency possible. CMAF on the other hand, is a reworking of an older streaming method.
CMAF was designed to lower the incredibly high latency involved in HTTP delivery without having to rethink the overall strategy of using HTTP. This also made it easier on CDNs since they didn’t have to change their entire strategy and infrastructure. However, this approach is still not not low enough for real-time interactivity. No matter what is done to CMAF it’s still based on the older (and slower) HTTP method. As such, this makes CMAF a stop-gap solution rather than an actual fix the problem of latency in live streaming.
Unlike TCP-based HLS and MPEG-DASH, WebRTC is UDP based. UDP is not concerned with the order of the data, rather it delivers each packet to the application the moment it arrives. Instead of queuing packets and waiting for them to load like TCP based protocols, WebRTC focuses on the dropped packets. This is done either by using NACK to retransmit the most critical packets or by Packet Loss Concealment – estimating to some extent what should have been in the missing packet.
Those already familiar with WebRTC may correctly point out that WebRTC can also deliver over TCP. However, since this method is mostly used as a back up when firewalls block UDP traffic, we don’t dwell on it in this post.
In real world tests, CMAF produces 2-3 seconds of latency, while WebRTC is under 250 milliseconds. This makes WebRTC the fastest, streaming method.
CMAF vs WebRTC: How Do They Send Media?
In order to transmit each CMAF Segment, a POST request containing a CMAF Header is sent to the ingest origin server. Immediately after each CMAF Chunk completes encoding and packaging, it is sent through HTTP 1.1 chunked transfer encoding. This means that each segment can be progressively delivered as each chunk is ready rather than waiting for the entire segment to load before it can be sent out.
Then, the chunks ingested into the origin are delivered over HTTP chunked transfer encoding to a CDN where Edge servers make them available to the players which will eventually display the media. In order to retrieve the segment, the player uses the manifest or playlist associated with a stream to establish a connection with the correct Edge and then it makes a GET request.
WebRTC goes through “media channels”. These use either SRTP (for encrypted voice and video) or SCTP (for the encrypted data channel). The actual video itself is sent using different codecs. In the case of Red5 Pro, the primary codecs used are H.264 for video and AAC for audio. However, other codecs, such as VP8 and VP9, can be supported as well.
Which Protocol Is Right for Your Use Case?
Choose CMAF if you need:
- High-quality, broadcast-style video at scale, including 1080p and 4K delivery.
- Efficient one-to-many distribution using existing CDN infrastructure.
- Predictable playback for large audiences where interaction is limited.
- Lower latency than traditional HLS or DASH without fully rearchitecting your streaming pipeline.
- A proven model for live sports, large events, and high-traffic product launches.
- CMAF is best suited for scenarios where video fidelity, reach, and delivery efficiency matter more than instant interaction.
Choose WebRTC if you need:
- Sub-second or real-time latency for interactive experiences
- Tight synchronization between video, audio, and user actions
- Dynamic, two-way communication such as auctions, betting, collaboration, or conferencing.
- Real-time quality adaptation to changing network conditions
- Large-scale interactive streaming built on SFUs and cloud-native orchestration
- WebRTC is the better choice when responsiveness and immediacy are core requirements, even if that means trading off some delivery efficiency or relying on more active infrastructure.
In practice, the choice comes down to scale versus immediacy. CMAF excels at delivering the same high-quality stream to massive audiences efficiently. WebRTC excels at keeping participants synchronized in real time, enabling interaction that buffered streaming protocols cannot support.
What is CMAF?
CMAF is a standardized container designed to package video, audio, or text data that is delivered using HTTP based streaming protocols: HLS, LHLS, or MPEG-DASH. HTTP protocols divide a video stream into small chunks which reside on a HTTP server. In this way the individual video chunks can be downloaded by a video player via TCP.
CMAF defines the segment format as well as codecs and media profiles that will be used to deliver the stream.
The advantage of CMAF is that media segments can be referenced simultaneously by HLS playlists and DASH manifests. This allows for the support of various devices without having to store multiple copies of the same stream content with different encoding for different formats. CMAF eliminates the need for redundant storage of the same video file by using one file format that could be used by different devices.
A big disadvantage is that (like other HTTP based protocols) it cannot produce a low enough latency for real-time live streaming with a latency of 2-3 seconds. We will cover latency in more detail later on.
What is WebRTC?
WebRTC (Web Real-Time Communication) is a standards-based, open-source project supported by Google, Microsoft, Mozilla, Opera, and Apple. Essentially, it is a media engine with a JavaScript API on top of it. It supports both direct peer-to-peer (p2p) connections and server-assisted topologies such as SFUs, and is supported natively with standard browser APIs, making it suitable for real-time streaming, communications, and interactive applications. WebRTC streaming is still king in 2025, enabling sub-250 ms latency for true real-time scenarios. Learn more about this protocol from our blog “What is WebRTC?”
It works directly in a web browser without requiring additional plugins or downloading native apps. It does not use HTTP to send any media. Instead, it establishes a connection using UDP and delivers encrypted video over RTP. As such, WebRTC produces the lowest possible latency of 250 milliseconds or less. This level of responsiveness is often described as streaming at the speed of thought because human perception cannot register machine level zero latency, making sub-250 ms effectively instant for users. Learn the most common WebRTC terms on this page. WebRTC scalability is already proven in real-world deployments.
If you want to try it right now, you can visit our WebRTC demo and see real-time performance in action. What’s important today is synchronization of user experiences, you don’t want updates to arrive at different times particularly for live events.
Conclusion
CMAF vs WebRTC comes down to the tradeoff between scalability and real-time interaction. CMAF is better suited for large-scale, broadcast-style streaming where high video quality and efficient CDN delivery matter most, while WebRTC is designed for sub-second latency and fully interactive experiences. Choosing the right protocol depends on whether your use case prioritizes reach and consistency or immediacy and synchronization.
