DEV Community: Red5

What is WHIP and WHEP? Creating Simpler and Faster WebRTC Connections

Maria Artamonova — Mon, 02 Nov 2026 05:00:52 +0000

WHIP and WHEP are the newest additions to the WebRTC ecosystem, designed to simplify how real-time connections are made. In this blog, you will learn what these protocols are, how they work, why they matter, and what benefits they bring to developers and enterprises.

What is WebRTC?

WebRTC or Web Real-Time Communication protocol is an open-source technology that enables real-time communication directly in the browser without plugins. It powers use cases like video calls, news and sports broadcasting, live events, video surveillance, live auctions, sports betting, and other interactive applications. With WebRTC, you can achieve ultra-low latency streaming, making it ideal for experiences that require instant viewer interaction.

The WebRTC connection setup of yesteryear, and largely still today, is something that can drive a nuts and bolts networking-type crazy. It’s a signaling setup that involves multiple back-and-forth communications to put together offers and answers in an attempt to agree on the basics that are needed to set up a communications channel. Just about anything that can be done to simplify this process is an improvement. This is where WHIP and WHEP come into play.

What is WHIP?

WHIP is the WebRTC HTTP ingestion protocol that simplifies how publishers send their media streams to servers. The idea is simple: either single or tiny subset of HTTP calls to set up communication over HTTPS instead of multiple calls via a WebSocket. Instead of chatting back and forth with offers, answers, candidates, the initiating client packages its offer in a request, and the response returns with both the answer and the Interactive Connection Exchange (ICE) candidates.

A client wishing to start a publishing session uses WHIP, emphasizing the “I” for ingest. In the initial connection, the client specifies its Session Description Protocol (SDP) offer in an HTTP POST to the server with which it wants to connect. The server responds with the SDP answer and information about the ICE candidates. Previously, this would have required several messages back and forth, adding latency to connection establishment. Using the provided ICE candidates, the publisher attempts to establish a connection, with ICE helping this connection traverse Network Address Translation.

WHIP clients use the Session Description Protocol (SDP) to describe media capabilities such as codecs, resolution, and audio setup. The whip server responds with an SDP answer containing matching details and ICE candidates that help establish connectivity across different networks. The whip endpoint acts as the entry point for publishers to send their streams to media servers or other ingestion systems. The whip specification defines how HTTP requests carry this information to make setup faster, more predictable, and compatible with existing web infrastructure.

Benefits of WHIP

Simpler connection setup: WHIP reduces signaling complexity by allowing a single HTTP request to exchange offers and answers, cutting down on multiple round trips.
Sub-100ms latency: Since connection establishment requires fewer steps, publishers can achieve sub second latency from the video source to the server.
Better compatibility: WHIP uses native HTTP, making it compatible with existing web infrastructure, proxies, and load balancers.
Faster integration for developers: With fewer moving parts, developers can configure, publish, and manage streams with less custom code and fewer errors.
Improved scalability: Its lightweight approach makes it easier to scale ingestion endpoints across distributed architectures like Kubernetes.

What is WHEP?

WHEP is the WebRTC HTTP egress protocol that makes it easier for browsers and applications to receive real-time streams from media servers. Like WHIP, it simplifies connection setup by combining offer and answer exchange into one HTTP POST call. The response includes ICE candidates, allowing fast and reliable connectivity.

In WHEP, the emphasis is on “E” for egress. The WHEP protocol allows a viewer or WHEP client to request a stream through a WHEP endpoint, where it sends an SDP offer and receives an SDP answer in return. This process establishes the connection with the WHEP server, completing setup in a single call. ICE helps finalize the connection for the subscriber.

By simplifying the egress side of WebRTC, WHEP improves playback reliability and startup speed, allowing users to start watching live streaming content more quickly without waiting for multiple signaling steps.

Benefits of WHEP

Instant playback start: The single-request mechanism of WHEP reduces setup time, allowing near-instant video stream playback.
Simplified architecture: Developers can connect players directly to the whep endpoint, removing the need for extra signaling servers.
Compatibility with media infrastructure: WHEP works smoothly with existing media servers, making it easier to integrate into current workflows.
Efficient resource management: With fewer calls and less signaling, WHEP conserves bandwidth and improves the quality of video stream delivery. For real-time WebRTC delivery, efficient bandwidth usage is only part of the performance equation; understanding the relationship between available network capacity and delivery delay is also important, as explained in our guide to bandwidth vs latency.
Flexible deployment options: Its native use of HTTP allows deployment across cloud environments and tools that already handle REST APIs.

How WHIP and WHEP Compare to Each Other?

Both protocols simplify the WebRTC connection process and help achieve sub-second latency by minimizing the signaling steps needed to establish communication. Let’s take a look at how WHIP and WHEP streaming protocol compare to each other.

In practice, developers can use both together to create a complete real-time workflow that is easier to manage and scale..

Why switch to WHIP and WHEP?

The market is interested in simplification and reducing the amount of time it takes to establish a connection. By switching to WHIP and WHEP, connection setup time is improved, and development is simplified by reducing the complexity of signaling to a single call.

At Red5, we are approaching it this way: simplifying how publishers and subscribers connect to ensure faster setup and improved quality of experience. This implementation reduces dependencies and enables flexible configurations within distributed clusters.

Additionally, using WHIP and WHEP simplifies connection setup in multi-server environments, allowing for either a single call to a Stream Manager or direct connections to Origin or Edge nodes. This opens new opportunities to scale deployments efficiently, especially when using load balancers or Kubernetes-based systems.

It is important to note that WHIP and WHEP are still in draft form. Early implementation across encoders and players can vary, and developers might need to adjust configurations to match each platform. The expectation is that once ratified, interoperability will improve as the community adopts the standards more broadly.

At the moment, organizations that depend on live streaming with ultra-low latency can expect WHIP and WHEP to deliver strong results. While some limitations remain in interoperability, the value they offer lies in easier management, simpler integration, and better scalability.

Conclusion

If you read nothing else, remember this: WHIP simplifies publishing, WHEP accelerates playback, and together they make real-time live streaming easier to build, run, and manage by turning multi-step signaling into a single HTTP request and response.

FAQs

What does WHEP mean?

WHEP stands for WebRTC HTTP Egress Protocol. It defines how clients can request and receive a video stream or audio feed over standard HTTPS without complex signaling. The WHEP endpoint handles setup through a single HTTP request, making live streaming playback faster and easier for browsers and applications.

What does WHIP stand for?

WHIP stands for WebRTC HTTP Ingestion Protocol. It allows publishers or encoders to send audio and video streams directly to a WHIP server or WHIP endpoint using a single HTTP POST. This reduces latency and simplifies setup compared to traditional multi-step WebRTC signaling.

Does OBS support WHIP?

Yes. OBS Studio supports WHIP through community plugins, allowing any compatible encoder to connect directly to a WHIP server. Red5 is one of the recommended platforms by OBS for WHIP streaming, providing a reliable and standards-compliant implementation.

5 Key Reasons AV1 Will Play a Big Role in WebRTC Streaming

Maria Artamonova — Sun, 01 Nov 2026 05:00:55 +0000

In this blog, you will learn why AV1 is getting closer to practical use in WebRTC-based real-time interactive streaming. We cover rapid progress in live AV1 encoding on GPUs and ASICs, widening browser and device support, and new WebRTC compatibility work like SVC and RTP payload formats. You will also see how Red5 Pro’s XDN and LCEVC can lower compute costs and expand device reach as AV1 adoption accelerates.

Advances supporting the next-generation AV1 codec have intensified over the past year, adding new urgency to the question of when the technology might become useful in WebRTC-based real-time interactive streaming applications.

There’s no question live video encoding supported by AV1 would benefit real-time streaming every bit as much as it stands to benefit traditional HTTP streaming. The codec achieves bitrate reductions in the range of 30%-40% compared to HEVC/H.265 and 60%-70% relative to AVC/H.264. Moreover, AV1 is available royalty-free with major tech sector backing through the Alliance for Open Media (AOMedia), whose members include Amazon, AMD, Apple, Cisco, Google, Hulu, IBM, LG, Meta, Microsoft, Netflix, Nvidia, Intel, IBM, Samsung, and many other leading players.

But the amount of computing power it takes to run the encoding and decoding processes has been a major impediment to AV1 adoption, especially when it comes to encoding at live video frame rates. As demonstrated in countless tests, there’s been no practical way to use AV1 to encode video in real time except at very low levels of resolution. For example, a series of recent tests conducted by cloud CDN and compute platform operator Cloudflare found that even if all 48 cores of the top-line AMD EPYC 7642 CPU processor were used to encode a 4K clip commonly used in such testing, it would take 43 seconds to encode two seconds.

But the perspective on the possibilities is shifting rapidly. And we at Red5 Pro are paying close attention to developments.

1. AV1 Live Encoding Is Closer than Ever to Commercial Viability

In 2021, Google released its desktop Chrome 90 browser with an AV1 encoder optimized for video conferencing with WebRTC. The encoder is targeted to two- to four-core CPUs for 2 Mbps transmission of 720p video at 30fps. This points to the fact that encoding AV1 for low bit-rate transmissions at sub-1080p levels is now doable on most PCs, which means the codec can be widely used to get decent-quality video over low-bandwidth mobile links that are the sole means of internet access in many parts of the world.

Cisco took another step in this direction in 2021 on the fringes of its Webex video conferencing service. The company now gives users the option to turn on live AV1 encoding to improve the quality of shared displays of video clips during conference calls.

Anyone on such a call with a device capable of decoding a low-bitrate AV1 stream will see the clip with much greater clarity. Cisco said it expects to expand the use of AV1 on Webex over time but had not announced any further steps as of YE 2022.

A much more dramatic sign of progress on the AV1 encoding front came in late 2022 with the introduction of powerful new AV1-enabled graphics engines by Intel, AMD, and Nvidia. As of this writing, for the first time, live AV1 encoding in fast-action gameplay can be executed by some versions of Intel’s Arc Alchemist and Nvidia’s RTX 4000 series running on gaming cards, which became commercially available in October. AMD released its far less expensive RX 7000 platform in early 2023 with no lofty claims for live AV1 encoding. Even so, early comparisons of the three tech companies’ latest advances, like this one reported by PC World, found them more or less on par with one another when it came to AV1 encoding of content for recording and archival usage.

It’s clear the AV1 live streaming barrier has been broken for gamers who want to shell out $1,500 or so to purchase the Intel or Nvidia gaming cards now on sale from multiple vendors. For example, testing of live video encoding with Intel Arc’s AV1 encoder against leading H.264 GPU encoders, as reported by PC World, found that when set to encode HD 1080p video at 3.5 Mbps, the quality of the video is superior to the output of H.264 encoders delivering the content at nearly twice that bitrate.

Of course, GPU cards significantly outperform encoders running on CPU cores or CPU cores enhanced with GPU acceleration, which remain the primary encoding engines in OTT streaming services. But these latest GPU platform advances point to the likelihood that the densification and architectural advances achieved with gaming encoders will be adopted in succeeding generations of hybrid CPU/GPU processors.

Another hardware advance signaling a role for live AV1 encoding occurred at the 2022 IBC trade show in Amsterdam, where RealSprint, the Swedish company operating the Vindral CDN service, revealed it would be introducing AV1 live encoding on its platform using ASIC (application-specific integrated circuit) hardware technology from NETINT Technologies. NETINT’s low-latency 4K AV1 encoder harbingers the emergence of ASICs as a potential game changer in advanced codec operations, according to NETINT COO Alex Liu, as quoted by Streaming Media. “[These applications] can only be met with ASIC hardware encoding,” Liu said.

2. Browser, Player Support for AV1 Decoding Is Gaining Wider Traction

Meanwhile, on the decoding side, there’s been a surge in browser and app support for AV1 software decoding on high-power devices. For now, this means that entities streaming on-demand content can use AV1 encoding with high confidence that a growing share of users will be able to take advantage of the bandwidth savings, which are beneficial to distributors as well as receivers.

The Google-backed Chrome browser and apps based on Android 10 or later can support software-based AV1 decoding on any device with enough processing power to accommodate the codec. Firefox, too, supports AV1, as does the Edge browser when used on PCs running Windows 10 or later.

Apple’s Safari browser and iOS operating system are holdouts, but it’s generally assumed that Apple, as a member of AOMedia, will fall in line at some point. Notably, the AVPlayer API incorporated with iOS and tvOS now offers optional support for AV1, meaning any app providers who choose to use the player can deliver AV1-encoded content to most iPhones and all TVs connected to the Apple TV module.

It’s important to note that browser and OS support for AV1 isn’t essential in the case of apps that incorporate support for the codec in their encoding and player software decoding mechanisms as long as targeted devices have the CPU or CPU with hardware acceleration resources to support decoding. Meta, for example, which has bypassed the inclusion of HEVC with its Facebook and Instagram Reels video apps in favor of using AV1, is finding more iPhones than Android mobile devices have enough hardware processing power to handle the codec.

Citing a talk given by Meta software engineer Ryan Lei at the company’s Video @Scale Fall 2022 conference, the NETINT blog post reported Meta uses H.264, VP9, and AV1 to encode Reels and that it streams content using the most efficient encodes supported by targeted devices. Meta has found VP9 produces a 48% bitrate savings compared to H.264, while AV1 cuts the H.264 bitrate by 65%. Meta chose AV1 over HEVC based on tests that showed AV1 delivered a 30% improvement over HEVC.

Netflix, too, has found it makes sense to take advantage of AV1. It began using the codec for streaming its content to Android mobile devices in 2020 and, a year later, said it would use AV1 to stream content to any smart TVs that could support the decoding. At the time, Netflix said these included a wide range of Samsung TVs dating from 2020, as well as any TV connected to PlayStation 4 Pro, Amazon Fire TV running Fire OS 7 or above, and Android TV devices running Android OS 10 or above.

Netflix recently issued stats attesting to the benefits to be gained even at this early stage through more advanced alternatives to H.264 encoding. The streaming giant reported analysis of its output during one month in early 2022 showed that its contribution to global traffic volume would have been 24% higher without its reliance on per-title optimized HEVC and AV1 encoding. The company said these advances, along with its CDN-related Open Connect Program, had contributed to over $1 billion in savings for ISPs in 2021.

3. Device Hardware Support for AV1 Decoding Is Picking Up Steam

These developments are moving in tandem with ever more support for AV1 among device OEMs. Some of this support is in response to pressure from Google, which in 2021 began requiring AV1 decoding support in all new Android TV and Google TV smart TVs, media dongles, and set-top boxes. In addition, AV1 hardware decoding is built into the latest Chromecast TV streaming adaptor and the Tensor chipsets powering the latest Google Pixel smartphones.

Beyond the Google orbit, the push from Netflix, AOMedia member Hulu, Meta, and other major players looking to exploit AV1 is persuading chipmakers and OEMs to incorporate direct support for AV1 decoding in their hardware processing, thereby eliminating the need for software decoders in app-based players.

Hardware-accelerated AV1 decoding is fast becoming a ubiquitous feature of new smartphones regardless of the relationship to Android. AV1 decoding is already built into the Samsung Exynos 2200 and MediaTek Dimensity 1000 SoC smartphone chipsets. And Qualcomm, by far the dominant microprocessor supplier for Android smartphones, has broken with its avoidance of hardware decoding support for AV1 with an announcement that its forthcoming Snapdragon 8 Gen 2 chipset will support AV1 playback for HD and UHD formats extending to HDR (high dynamic range)-enhanced 8K.

As for smart TVs, beyond the Samsung models cited by Netflix and those like Sony’s Google TV model that have built-in hardware decoding support for AV1, new models from LG, Sony, Philips, TLC, and probably others are running on chipsets that can accommodate AV1 processing. But none of these brands have spelled out what, if any, steps they’ve taken to create the algorithmic paths in their firmware that would enable decoding without the aid of player software.

This may be the next shoe to drop as AV1 momentum builds. For example, LG, acknowledging its latest models have the horsepower to support AV1 and many other “smarter features,” recently announced it had joined AOMedia “to work collaboratively to further the development and adoption of AV1-enabled innovative online video streaming solutions.”

Getting this right at the core hardware level isn’t easy. While LG had previously issued documentation for developers claiming support for AV1 on UHD TV sets running WebOS 5.0 or above, testing performed by Bitmovin in conjunction with its October AV1 report found that some of those LG models couldn’t handle AV1 content. With this new commitment to the codec, that’s likely to change.

OEMs’ reluctance to expend more energy on AV1 support likely has to do with the fact that, until recently, the codec profiles hadn’t clearly spelled out support for HDR processing. This has been rectified with documentation clarifying how to use HDR 10 and 10+ with AV1, with work on Dolby Vision still in progress, according to Netflix senior research scientist Andrey Norkin. As reported in September by Streaming Media, Norkin said Netflix, which uses HDR with all its original content, has begun testing how AV1-encoded HDR video performs in playback with players that have been tweaked to support HDR.

4. WebRTC & AV1 Are More Compatible than Ever

Clearly, AV1 has a strong toehold in the marketplace with the potential to burst into the mainstream once live video encoding becomes practical. Fortunately, whenever that happens, putting AV1 to use with interactive real-time streaming over WebRTC will be a fairly straightforward process, thanks to preparations for that eventuality that are already or close to being baked into both standards.

The two protocols are intrinsically compatible, as noted two years ago by Bernard Aboba, chief architect at Microsoft and co-chair of W3C WebRTC and IETF Web Transport working groups. In an interview posted on the webrtcHacks site, Aboba said, “AV1 doesn’t require any changes to WebRTC PeerConnections per se….I think of it as the next in the lineage of VP8 [and] VP9….It has some H.264 kind of MAL (Multimedia Adaptation Layer) unit semantics, so it’s a little bit like a cross between H.264 and VP9.”

But he noted there were some important steps that needed to be taken in both development arenas to achieve smooth interoperability between AV1 and WebRTC. Since then, there’s been significant progress in this direction.

For example, it’s important that WebRTC be able to exploit Scalable Video Coding (SVC), which enables the generation of multiple content resolutions from a single encoder as a cost-effective alternative to server-side transcoding used with adaptive bitrate (ABR) streaming. AV1 is the first codec to incorporate SVC by default, and now completion of the draft Real-Time Protocol (RTP) Payload Format for AV1 specification within AOMedia has enabled AV1 SVC to be executed with WebRTC, which operates on RTP. In August 2022, WC3 issued SVC Extension for WebRTC as a draft specification spelling out the use of SVC with any type of codec used with WebRTC.

Another step toward compatibility involved aligning AV1 and WebRTC approaches to end-to-end security, which has been accomplished. Without going into technical details, key steps in this process have been the release of the RTP Payload Format for AV1 and the adoption of the IETF’s SFrame specification with the security intrinsic to WebRTC.

5. Red5 Pro Is Poised to Deliver Superior Results when Live AV1 Becomes Viable

So, now, the use of AV1 with WebRTC-based real-time interactive streaming (RTIS) platforms, including Red5 Pro’s XDN, primarily depends on when encoding support at high video profiles becomes practical. While, as noted above, standard-issue CPUs can support AV1 encoding with low-resolution video, which is helpful in the video conferencing business, XDN architecture is meant to provide support for scaling RTIS to an unlimited number of end users with sub-400ms latencies over any distance at levels of video quality common to live-streamed content.

Red5 Pro will be moving ahead with support for AV1 whenever it makes sense to put the codec to use on our platform. Judging by all the progress we’ve seen to date, those final steps are likely to be taken sooner than later.

Here it’s important to note that when that happens, XDN users will have the option to exploit much greater encoding efficiencies with AV1 than they’ll find in other real-time streaming scenarios. This results from the integration of XDN with the performance-enhancing capabilities of a software codec processing layer defined by the new MPEG-5 Low Complexity Enhancement Video Coding (LCEVC) standard. In late 2021 XDN became the first RTIS platform to include support for LCEVC in its SDKs.

As validated in recent tests conducted by Meta and Intel, LCEVC enhancements used with AV1 encoding cuts computations by about 40% with no loss in quality. And LCEVC was shown to broaden the set of mobile devices capable of playing back full HD AV1 content while extending battery life by 50% compared to non-enhanced streams using state-of-the-art AV1 software decoders.

Critically, there’s no disruption to connectivity with devices that don’t support LCEVC. Any devices not equipped with the lightweight LCEVC player will interact with the LCEVC-enhanced AV1 encoding at the native AV1 level.

As described in this blog, LCEVC has been proven to offer similar benefits with all codecs, including the ability to significantly reduce bitrates at a given level of quality, if that is the goal. In such cases, compression gains of about 40% are achieved with no increase in computational complexity, which, for example, is tantamount to reaching HEVC levels of compression with H.264 codecs.

As we await further developments in accelerated CPU support for live-stream AV1 encoding, we are also mindful that HEVC, with its substantial gains over H.264, has now reached mass market penetration at the hardware level in smartphones, smart TVs, and other devices. Be sure to stay tuned for further developments on this front, as well.

With video streaming moving into a new era of multi-codec options extending compression efficiencies far beyond the H.264 baseline, we’re just at the beginning stages of the advancements that will be essential to meeting the challenges ahead. Graphic realism in multiplayer gaming, fully immersive social engagement in virtual reality, 8K video entertainment, and the need for superior quality video in every use case where RTIS is in play will require aggressive but cost-effective use of the best compression technology available at every step of the way.

Conclusion

AV1 is moving from promise to practical, but it is not a turnkey replacement for real-time today. Hardware, browser, and player support are expanding while GPU and ASIC advances reduce the live-encoding compute barrier, and WebRTC compatibility via SVC and RTP payload work is in place. Expect multi-codec workflows for now; Red5 Pro’s XDN will add AV1 where it makes sense and use LCEVC to cut compute and extend device reach. If you want to see how AV1 compares with VP8 and VP9, or how the AV1 codec compares to H.264 and to H.265, or how H.264 compares with H.265 and VP8, read our next blogs.

Red5’s Predictions for the Live Streaming Industry in 2023

Maria Artamonova — Sat, 31 Oct 2026 05:00:54 +0000

Predictions for the live streaming industry in 2023 reflect how quickly real-time video continues to evolve across technology, business models, and user expectations. In this blog you will learn how live streaming infrastructure is changing, which trends will shape latency, scalability, and what these shifts mean for companies building or investing in real-time video solutions.

As 2022 comes to an end, we thought it would be fun to reflect back on the year, as well as to look forward at what’s on the horizon. Red5 CEO Chris Allen and CTO Mark Pace sat down to chat highlights from the past year and predictions for 2023. Here are the key take-aways from the discussion:

Looking Back at 2022

Attending lots of conventions: After the lockdown and travel restrictions, it was fun to finally see people in person and reconnect. It was also great to visit some clients on-site and get a better sense of their needs.
ChatGPT and the rise of AI: AI was hot this year. It was writing and coding for us (ChatGPT), creating art (DALL·E, Deep Dream Generator), and even tricking us with deepfake imagery. It will be interesting to see how this trend disrupts (for better or worse) the worlds of education, art, and creativity in general. On an aside, we had fairly good success with generating AI-generated technical documentation. Where will this lead us? Will the robots take over? Do you want to play a game?
Live video streaming sports in real time has come into its own: It’s been a long journey, but we’re seeing forward movement in this realm. Companies are starting to embrace the technology and see the value that it can provide for their customers. We’re excited to see how this plays out in the realm of sports streaming and broadcasting, online betting and micro-betting.
Red5 Mixer and Watch Party Technology: The Watch Party has created a lot of “aha” moments as people start to see some of the possibilities out there. But the best part may be that this open-source option is out there for people to build on and innovate.
Crypto in Flames: We knew there were some unsavory players out there who were having a negative impact in the field, but we certainly didn’t predict the fiery glory of the 2022 crypto meltdown.

Looking Forward to 2023

More Codecs: It may not sound too sexy, but we’re excited for more codecs bringing higher resolution and less bandwidth to the table. It looks like 2023 will also bring wider adoption of H.265 and AV1, as devices become more powerful. Standardization around WHIP and WHEP: WebRTC is the gold standard for ultra-low latency live video streaming, so the standardization of WHIP and WHEP is something the entire industry is looking forward to. We’ll see easier-to-use encoders and faster connection times. We’ll also enjoy greater interoperability between platforms and less debugging. Learn more about these two protocols from this blog.
Bantha Livestream: Join us live for mixed drinks, chats with industry leaders, new products and use cases, and thoughts on the state of the industry. We’ll be using Red5 open-source software that we’ve customized to power the experience.
An inflection point in social media: It’s still unclear what it will look like, but perhaps we’ll see open standards become dominant with options like ActivityPub, which is used by Mastadon. If social media can become more like email or standard web pages where they are fully interoperable between various platforms, we could move away from social media being controlled and owned by a handful of monolithic providers.
Shift in real-time interactive streaming (RTIS) providers: RTIS is seeing a lot of movement right now. There is a lot of demand for on-premise, self-hosted solutions, but many still want a turnkey hosted solution, as well. Red5 Pro will be introducing a hosted solution, making it easier for businesses who don’t want to deploy it themselves.
GovCloud: We’ll see more government cloud solutions and standards focus on live real-time video, creating more potential for high-security deployments. These run on high-level government clearance with high-security screening. In terms of encrypted WebRTC video, we have pretty sophisticated systems to secure the streams and connections in and out of them.
Edge computing is starting to deliver on its promise: Edge computing isn’t anything new, but it’s coming into its own with 5G getting to a point where it’s more widely available. We’re excited to see more and more Edge computing use cases, such as in stadiums, at sports events, etc.
Sports betting and live sports engagement: As mentioned above, live streaming is taking off in the sports realm. This has increased efforts to legalize online sports betting around the world. We know gambling is always popular, but we also think that sometimes it’s more about the user experience than the transaction. This might lead to micro-betting platforms that behave more like a trivia game than an actual financial wager. And, with technology like the Red5 Pro watch party, we could see fantasy football league apps, where friends watch a game with live league stats updating on-screen. Perhaps we’ll even see AI-generated highlight reels customized for your league players.
CDN: With the implementation of open caching architecture, CDNs will become more localized and more efficient.
Red5 Pro in cloud marketplaces with cloud vendors: We’ve launched in the Oracle Marketplace, but we won’t stop there!

Conclusion

Here at Red5 Pro, we never stand still. As we head into 2023, you can expect more innovations, including new open-source features like the watch party that you can take and make your own. With so many opportunities for new use cases, we hope you’ll hop on board.

How to Set Up 4K Streaming At 60fps from Osprey Talon Encoder and Red5?

Maria Artamonova — Fri, 30 Oct 2026 05:00:53 +0000

4K streaming is becoming increasingly popular in 2025 as more businesses prepare for higher-quality video demands. We’re happy to teach you how to set up 4K streaming with Red5 Pro or Red5 Cloud and the Osprey Talon encoder using our step-by-step tutorial.

Real-Time Interactive Streaming in 4K

If 4K is the standard in broadcast, you might be wondering why it’s so challenging to stream. Just as the broadcast industry had to go through major upgrades to support 4K, the streaming industry does as well. Red5 also has the need for interactive real-time latencies, adding further computational complications.

In order to get that amazing 4K picture, you need to deliver four times as many bits to the screen as with 1080p. And then you have to double that rate once more to stream at 60 frames per second. There are newer codecs to help with this, but, until more devices support AV1 hardware acceleration or the industry fully supports H.265 for WebRTC, we are stuck streaming with older protocols like H.264. To learn how the AV1 codec compares to H.264, read our next blog.

The first problem when heading into this realm is how to generate a 4K stream to send to your ingest. Enter the Osprey Talon encoder. It features the AMD Xilinx Ultrascale+ Architecture at its core, giving the unit the ability to stream 4K at 60fps.

About the Osprey Talon Encoder

Osprey Video is a global manufacturer of hardware encoders that perform a critical yet understated task of ingesting RAW video, converting that into a compressed digital format and serving as the on-ramp to video delivery and archiving platforms. They are one of our hardware partners. You can read more about this company in this study.

The Osprey Talon encoder comes in two form factors, one including 12G-SDI in/out and HDMI and another with a single 12G-SDI in. Both feature the same chipset. Via this chip, Osprey Video was able to attain its goal of achieving the lowest latency while not sacrificing quality. This allows the Talon to encode up to 4K 60fps in 10-bit HDR (4:2:2) video.

Output transports include RTMP(S), MPEG-TS uni and multicast over UDP, RTP, Zixi, SRT, and WHIP. For recording purposes, the Talon can also save to an MP4 while delivering a stream. The Osprey unit supports AAC and OPUS audio in both 44.1 and 48KHz sample rates. Embedded 708 captions are supported, as well as the ability to send KLV metadata. The units themselves are essentially heat sinks, allowing the Talon to operate without a fan and the accompanying noise.

In addition to supporting H.264, the Osprey units also support H.265. Unfortunately, H.265 is not going to be a viable codec for use with WebRTC, so we will continue to focus on H.264 until more client device hardware supports AV1.

A web interface is provided to configure the Talon encoder. It provides quick access to the configuration of the encoder as well as the configuration of its output.

How Does 4K Video Streaming with the Osprey Talon Encoder and Red5 Work?

To test the Talon, we needed a high-quality 4K 60fps stream. To add to the fun, we decided to create a streamed game experience using Forza Horizon 5 from an Xbox Series X as our source. The Talon encoder sent the Xbox’s 4K 60fps stream to a geographically close datacenter running a Red5 Pro cluster. Because there is no channel for controlling the game via the stream at this juncture, the controller was not streamed and was connected locally to the Xbox.

Diagram illustrating how Osprey Talon encoder sends 4k 60fps video stream from Xbox to Red5 Pro.

With the equipment configured as shown in the diagram, the stream quality was optimized to allow for driving. The Xbox was connected via HDMI to the Talon encoder. This encoded the 4K stream into H.264 and sent it to the Red5 Pro cluster using SRT. The stream passed from Origin node to Edge node in the cluster and then made its way back to the PC where the game stream was displayed to the player.

Using RTMP

Here we cover RTMP/S via Talon

Additional settings are all the same as with WHIP above, except for audio where it will be AAC instead of Opus.
Under Channels, select Channel 1.
Select “RTMP/RTMPS” for Protocol.
Destination will be set to your RTMP end-point location; as an example: rtmp://myserver.red5pro.net/live.
Stream key is set as stream1.

Using SRT

The SRT option allows either h.264 or h.265 for video encoding. Starting with h.264 here are the configurations:

Under Channels, select Channel 1.
Select “TS over SRT” for Protocol.
SRT Mode is to be “Caller”.
SRT Dest Address will be set to your “Listener” end-point location; as an example: myserver.red5pro.net
SRT Port is 8000 in this example, it may need to be changed for your deployment.
Select your Source either SDI or HDMI.
Set Output Resolution = 3840×2160 (4K).
Set the Framerate (30 fps or 60 fps depending on your workflow).
Codec is H264/AVC.
Target Bitrate 12000.
Maximum Bitrate 25000.
Encoding Profile should be “Baseline”.

5. Verify Red5 Settings

Log into your Red5 Pro server (or Red5 Cloud dashboard).
Make sure the live application is enabled and properly configured to ingest RTMP, WHIP, or SRT.
Check firewall rules to ensure port 1935 (RTMP) or relevant 443 (HTTPS) port is open. In addition to any SRT ports configured, such as 8000.

6. Start the 4K Stream

On Osprey Core, click Start Stream.
Monitor encoder health stats (bitrate, frame drops, etc.).
On Red5 Pro, confirm the stream is being ingested (you can use the Red5 Pro web player, or connect via a player configured for your stream URL).

7. Test Playback

Open a WebRTC or HLS player pointing to your Red5 Pro or Red5 Cloud stream.
Confirm video is delivered in 4K resolution and sync.

8. Optimize for Quality and Latency

Adjust encoder bitrate if you see buffering or quality drops.
Use H.265/HEVC for more efficient bandwidth usage if supported by your Red5 Pro setup. HEVC is only available on the Talon if SRT is used for output.
Enable adaptive bitrate (ABR) streaming in Red5 Pro if you expect varied end-user connections.

When optimizing a live stream for changing network conditions, it is also important to understand how available bandwidth and delivery delay interact; see our guide to bandwidth vs latency.

Red5 and Osprey Video About The Solution

Our Talon 4K Encoder platform ingests 12G video and delivers reliable, high-quality, secure, low latency streams to Red5. Needs for ingesting video on the edge in true 4K with 10-bit color in multiple protocols are increasing daily. The Talon 4K’s small form factor, fanless operation, and intuitive UI make it simple for customers to address these needs and provide delivery for multiple applications.”

– Scott Whitcomb, Chief Revenue Officer at Osprey Video

The Osprey Talon encoder, when used with Red5 Pro, expertly streams 4K 60fps at incredible low latency. The encoder is full-featured and easy to configure, while also exposing advanced settings with detailed control when needed. We’re excited to support it and the future products in that line.”

– Mark Pace, Advisor, former CTO at Red5

Conclusion

Red5, paired with the Osprey Video’s encoder, enables high-quality 4K 60fps live streaming with ultra-low latency. Supporting protocols like WHIP, RTMP, and SRT, it offers flexible configuration through a web interface and integrates easily with Red5 Pro or Red5 Cloud for real-time delivery.

How to Unleash GStreamer for Low Latency Streaming with Red5?

Maria Artamonova — Thu, 29 Oct 2026 05:00:49 +0000

The use of GStreamer for low latency streaming has been gaining momentum since 2022 as more developers build real-time and interactive video applications. GStreamer’s flexibility, plugin ecosystem, and cross platform support make it a strong choice for handling complex streaming workflows, but achieving true real-time performance comes with specific challenges.

In this blog you will learn what GStreamer is, how it operates in low latency environments, why you should use it and for which use cases, how Red5’s XDN architecture enhances the GStreamer workflows for real-time streaming including multi-protocol streaming, and more.

What Is GStreamer?

GStreamer logo.

GStreamer is an open-source framework provides vendors a common approach to offering commercial solutions as plugins that developers can bring into their service pipelines with a few mouse clicks. Plugin elements relating to operating systems, codecs, streaming modes, editors, filters, feature functionalities, descriptive metadata, and much else can be mixed and matched to support just about any multimedia application at any point in the distribution chain, from video capture to device playout. You can learn more about from the official website.

Why Should You Use GStreamer in Real-Time Streaming Environment?

But there’s a serious challenge when it comes to live-streamed content. The elements guiding encoding, packaging, categorization, rendering, and other aspects of content operations on a per-stream basis must perform their tasks in precise frame-by-frame synchronization with the primary payload no matter how many users are involved.

Efforts over the years that resulted in tight synchronization of elements used with payloads live-streamed over HTTP-based content delivery networks (CDNs) have been instrumental to expanding GStreamer adoption rates. The question now is whether the same will be true with real-time streaming platforms, which don’t rely on HTTP and where there’s no room for adding latency on streams traversing the GStreamer pipelines.

As in traditional streaming, developers focused on real-time streaming can benefit from the fact that GStreamer makes it much easier to evolve use cases by transitioning from simple to complex pipeline workflows through a consistent, standardized approach to tapping plugins for elements essential to any given task. By one count, there are 230 plugins cataloged in over 30 GStreamer libraries offering in excess of 1,600 elements supporting a vast range of functionalities.

The framework works with all major operating systems, including Linux, Windows, Android, Max OS X, iOS, and those based on Unix-derived platforms like Solaris and the Berkeley Software Distribution systems (BSDs). And it runs on 32- and 64-bit iterations of the leading hardware architectures, including x86, ARM, MIPS, SPARC, and PowerPC.

These attributes have provided developers with a powerful environment for keeping pace with evolving needs in the one-way streaming market. The benefits will be even more important to developers as the nuances bearing on the formats, range of devices, feature enhancements, user data analysis and much else grow more complex in the real-time interactive streaming era.

In What Use Cases It Can Be Used

As described in our recent white paper “XDN Technology Ignites a New Future for Targeted Advertising and Much Else“, the emerging generation of real-time video use cases extends across all segments of society.

In the consumer domain, they include the synchronization of shared real-time experiences with live-streamed sports, news, and other events, operations of e-commerce in all its permutations, and the vast realm of experiences tied to social networking, multiplayer gaming, and virtual and other versions of extended reality. An even greater variety of opportunities for developers can be found in the myriad ways enterprises, municipalities, medical professionals, educational institutions, the military, and other sectors are exploiting interactive video streamed in real time. The ability to leverage GStreamer in this environment is fundamental to everyone’s success.

A good example of both the nuanced variability and the precise synchronicity developers must accommodate can be found in applications that rely on the use of time stamping with GPS readings. An interactive real-time video streaming infrastructure with the scalability and performance parameters of the XDN platform can support frame-by-frame GPS accuracy in any use case that benefits from associating user location with interactive video engagement.

Another real-time usage scenario for GStreamer has to do with the aforementioned collaboration between hardware suppliers and developers in the creation and validation of approaches to exploiting next-generation microprocessor architectures. One such endeavor involves GStreamer innovator Fluendo’s work with Intel in efforts to facilitate developers’ use of the chipmaker’s Deep Link hardware-acceleration platform. As described by Intel, Deep Link technology uses dynamic power sharing and AI to harness CPU and GPU resources in devices to accelerate content creation, gaming, and productivity. Fluendo is developing GStreamer components to take advantage of Deep Link to enhance decoding performance in set-top boxes and other devices.

AI is a major force behind many other GStreamer development activities in the real-time streaming domain. Indeed, considering the pervasive presence of AI across all realms of consumer, business, government, medical and scientific activity, this is where the developer field of dreams approaches infinity.

A good illustration of how GStreamer is facilitating AI usage can be found in NVIDIA’s DeepStream SDK. Using an extensible standard structure for metadata, DeepStream enables the application of AI in GStreamer pipelines through batch-level and user-specific metadata to generate business insights, improve processing efficiencies, optimize edge-to-cloud connectivity, and execute the many other Intelligent Video Analytics (IVA) tasks in the NVIDIA plugin portfolio.

Through real-time connectivity, the SDK can bring multiple streams from different sources into play, NVIDIA notes. “Whether it’s at a traffic intersection to reduce vehicle congestion, health and safety monitoring at hospitals, surveying retail aisles for better customer satisfaction, sports analytics or at a manufacturing facility to detect component defects, every application demands reliable, real-time IVA,” the company says.

How Red5’s XDN Architecture Enhances GStreamer for Low Latency Streaming

There’s no doubt this can be done when it comes to activating GStreamer plugins with real-time streaming over Red5 Pro’s Experience Delivery Network (XDN) platform. Red5 Pro has taken multiple steps to ensure GStreamer pipelines designed for real-time use cases can operate on XDN infrastructure at any scale with tight synchronization across all elements.

This is vital not only to content flows targeted to end users. It’s also crucial to enabling plugin and applications developers to collaborate among themselves and with suppliers of core processors in order to fashion rapid responses to soaring demand for real-time solutions.

In all cases, GStreamer plugin operations benefit from the same mechanisms that ensure real-time synchronization of everything else that’s delivered on the XDN platform. Any number of users from a handful to millions can be simultaneously engaged with complex component-synchronized streams registering end-to-end latencies no greater than 250ms-400ms over any distance in any direction.

In some situations, latencies are reduced even farther, as when XDN infrastructure is instantiated in conjunction with AWS Wavelength facilities positioned with mobile carriers’ 5G onramps. See this blog for a description of the unique use of real-time streaming facilities with AWS Wavelength resulting from a new partnership between AWS and Red5.

Beyond these baseline contributions to effective use of GStreamer in live-streaming scenarios, Red5 Pro is working with others in the GStreamer space to perform integrations and customize XDN processes for specific types of collaborative development projects. Presently, for example, there’s a spate of activity in the accelerated hardware domain where CPU/GPU suppliers are working with developers to formulate the best approaches to utilizing hardware acceleration, often in conjunction with hardware prototypes that are still undergoing refinements based on market needs.

Whatever type of collaboration might be in play, XDN connectivity ensures everyone is participating in real time. We’ll take a deeper look at how the XDN platform facilitates the use of GStreamer in real-time streaming scenarios farther down. But, first, it might be useful to consider what the use of GStreamer in the real-time streaming environment means to the development community.

Addressing the Multi-Protocol Real-Time Streaming Imperative

In such scenarios, the streams delivered from video cameras need to reach all targeted endpoints, be they machines or people, with no increase in latency. A large share of live-streamed video is delivered in real time from streamers embedded in or attached to cameras via either the Real-Time Streaming Protocol (learn what it is here) or Secure Reliable Transport (SRT), neither of which is supported in the major web browsers. Consequently, use cases are better served when the streams can be delivered to their targets over WebRTC (learn what it is here), the real-time streaming platform that achieves broader reach by virtue of its support in all the major browsers.

Automatic, latency-free transition of RTSP and SRT streams to transport over WebRTC is one of the important roles played by XDN architecture in opening the world of real-time video streaming applications to GStreamer developers. Developers can utilize APIs in the GStreamer framework to manually set up the conversion of RTSP streams to WebRTC streams.

Moreover, developers pursuing this course would not benefit from the additional aspects of multi-protocol flexibility that come with reliance on XDN architecture. This flexibility stems from the fact that the platform uses the Real-Time Transport Protocol (RTP), which is the transport core for both WebRTC and RTSP, as the foundation for all streams delivered over XDN infrastructure.

By retaining the RTSP and SRT formats, the XDN architecture ensures that the content is received by targeted clients that support the stream-originating protocol but not WebRTC. The same principle applies to video ingested from sources that employ Real-Time Messaging Protocol (RTMP) and MPEG-TS (Transport Protocol).

In all cases, the automatic transition to WebRTC ensures the broadest possible reach through receptivity by all targeted devices that are compatible with at least one of the major browsers as well as devices without that browser support that are attuned to a given protocol used by the live-stream source. Moreover, in the rare instances when a targeted device doesn’t work with WebRTC or the originating protocol, the XDN platform streams the content over HTTP Live Streaming (HLS), which negates the real-time latency and multi-directional benefits but at least ensures no device is left out of the flow.

Beyond this multi-protocol flexibility, multi-cloud scalability and persistent performance are hallmarks of XDN architecture that are essential to any real-time streaming applications executed on GStreamer pipelines. Hierarchies of automatically orchestrated XDN Origin, Relay, and Edge Nodes can be implemented in cross-cloud configurations by leveraging pre-integrations with major suppliers like AWS, Google Cloud, Microsoft Azure, and DigitalOcean, or through integrations with many other cloud platforms enabled by Red5 Pro’s use of the Terraform multi-cloud toolset.

The XDN Stream Manager works in real time to orchestrate set-up configurations, load balancing, and traffic routing with fail-safe redundancy across all cloud instantiations. Automated scaling mechanisms enable real-time responses to fluctuations in traffic demand or the need to add new broadcasters and end users.

XDN architecture also provides full support for the multi-profile transcodes used with ABR streaming without imposing the latencies and other impediments incurred with HTTP-based streaming. It does this by utilizing intelligent Edge Node interactions with client devices to deliver content in the profiles appropriate to each user. In addition, as described in this blog, Red5 Pro is leveraging Edge Node intelligence to facilitate next-generation gaming, XR, internet of things (IoT), and other applications that depend on CPU/GPU processing at the deepest edge locations to achieve maximum reductions in latency.

Customized Approaches to Optimizing XDN Support for GStreamer Development

Adding to the benefits to GStreamer development stemming from these intrinsic capabilities, XDN architecture lends itself to customizations that can provide additional support for specific GStreamer projects. Notably, plugins associated with a given GStreamer pipeline can include elements that direct the use of XDN intelligence, servers, and other components to help execute applications.

By leveraging GStreamer APIs designed to support the use of JavaScript-based elements available in GStreamer Java libraries, Red5 Pro and its partners can formulate XDN functions utilizing a Red5 Pro service that employs WebSockets to receive and act on data tags within live streams. With WebSocket support for connecting client- and server-side Java code in XDN operations, partners can create Java-based applications in GStreamer that provide business logic for real-time communications, data gathering, edge-based analytics, and much else. The XDN utilizes the WebRTC datachannel to transmit all GStreamer-related communications.

Such capabilities have important implications for CPU/GPU suppliers who want to work with large communities of GStreamer developers to optimize the use of hardware for specific applications such as multiplayer gaming. Red5 Pro will be bringing some of these efforts to light in the months ahead.

Conclusion

Clearly, GStreamer will be playing an ever-larger role in bringing the new era of real-time video streaming to life. The fact that XDN architecture supports tightly synchronized real-time streaming over multiple seamlessly interconnected protocols and clouds opens a realm of virtually unlimited possibilities in the use of GStreamer to embellish real-time video services and applications.

How to Link Real-Time Live Streaming to Video-on-Demand

Maria Artamonova — Wed, 28 Oct 2026 05:00:49 +0000

Providers of livestreamed video services have reached a paradoxical moment of truth in network evolution where they can’t make the crucial leap into the future without retaining an anchor in the past.

As they implement new multidirectional streaming platforms to accommodate the changing dynamics in consumer engagement with live video, service providers must be able to rely on content delivery networks (CDNs) to support on-demand availability of their content. The question is, how can this be done without making an untenable tradeoff between performance and cost efficiency?

Real-Time Interactivity with Livestreamed Video Requires New Infrastructure

There’s no getting around the fact that the video streaming market can no longer operate with exclusive reliance on HTTP-based streaming over CDNs. These one-way infrastructures with their multi-second latencies and out-of-sync reception metrics are incapable of meeting the requirements of real-time video interactivity that have become entwined with livestreamed video.

Globally, as chronicled by Rethink Research, livestreamed video traffic volume is on track to surpass on-demand traffic in the months ahead. This coincides with demand for video-based real-time interactivity in the socialization of sports, esports, concerts, and other live-event viewing experiences.

The marriage of live streaming and video interactivity is also occurring with online video gameplaying, virtual and other extended reality environments, livestream shopping, online gambling, and all-virtual or hybrid versions of virtual with in-person auctions. And the integration of live and interactive streaming is intrinsic to surging community engagement with user-generated content (UGC) streamed on platforms like Facebook Live, Instagram Live, and TikTok.

Moreover, as described in many blogs, these shifting dynamics in leisure-time use of the internet parallel the worldwide movement toward the integration of online with real-world experience in hybrid approaches to everyday activities. Hybrid engagements with work, education, trade shows, and health care have become the new norm as humanity struggles to move beyond the Covid 19 pandemic.

Appending Interactive Video Communications to CDNs Doesn’t Address Market Needs

Livestreaming service strategies that rely on CDNs with ancillary attachments to video conferencing-type platforms supporting the interactive video components are rife with impediments to satisfactory results. They not only introduce operational complexities with limitations on quality and scaling of the interactive platforms; they also make it impossible to stream the source content with the real-time simultaneity essential to satisfactory user experiences.

The range of limitations common to ancillary video communications platforms is well illustrated by the handful of systems used to support video-based interactions in live event watch parties. Sling Watch Party, Yahoo Sports’ NFL mobile watch party app, and video chat apps available from other providers working with the NBA, soccer leagues, and other sports organizations all restrict watch-party participation to just a few users.

There are also video-chat platforms available from Facebook, Amazon, Hulu, and HBO Max, but these are limited to shared viewing of on-demand content, which makes it easier to ensure a group’s chosen video file is streamed at the same time to all participants over one-way CDN infrastructure. In virtually all cases, video-chat with live or on-demand content is encumbered by poor video and audio quality.

Similarly, attempts to employ traditional video conferencing platforms as adjuncts to CDNs in support of workplace virtualization and other hybrid applications fall far short of what’s needed. The highest levels of simultaneous user scalability top out at a few hundred participants, and many VC platforms set the maximum at under 100. Furthermore, virtually all restrict video quality to 720p HD resolution or below while limiting audio to voice-level frequencies.

As for CDNs, major efforts have been expended on latency reduction for live video streaming, but real-time connectivity remains out of reach with no means of ensuring simultaneous frame-by-frame reception across all end points. For example, end-to-end latency performances CDN operators claim to have achieved through Chunked Transfer Encoding (CTE) used with the Common Media Application Format (CMAF) bottom out at around two seconds but frequently go to four seconds and even higher. Apple’s latest low latency HLS (LL-HLS) improvement over the ubiquitous HLS protocol also gives performance of around 2 to 5 seconds of latency.

Enabling Real-Time Interactivity with no Scaling or Quality Limitations

In contrast, an infrastructure based on Red5 Pro’s Experience Delivery Network (XDN) technology enables video-rich source and USG payloads to be streamed in any direction to and from any number of end users at any distance. Everyone views everything at the same time with the delivery of content at imperceptible end-to-end lag times no greater than 400ms and often much less.

As described in greater detail in this white paper, everything essential to enabling multidirectional live streaming in real time from primary sources and any number of users is embodied in XDN architecture. The platform achieves the requisite scalability, quality, and other performance parameters with fail-safe redundancy through automated orchestration of hierarchies of origin, relay, and edge nodes in one or more cloud clusters.

XDN architecture makes use of the Real-Time Transport Protocol (RTP) as the foundation for streaming via WebRTC (Real-Time Communications) and Real-Time Streaming Protocol (RTSP). In most cases, WebRTC is the preferred option for streaming on the XDN platform because it is supported by all the major browsers, which eliminates the need for device plug-ins. This means any user accessing live streaming through Chrome, Safari, Firefox, Edge, or Opera can also participate in interactive video communications by sending their input over the XDN via WebRTC.

There are also other options for receiving and transmitting video in real time when devices are not utilizing any of these browsers. RTSP, often the preferred option when mobile devices are targeted, can be activated through Red5 Pro iOS and Android SDKs. And video can be ingested onto the XDN platform in other formats as well, including Real-Time Messaging Protocol (RTMP), Secure Reliable Transport (SRT) and MPEG-Transport Protocol (TS). The XDN retains these encapsulations while relying on RTP as the underlying real-time transport mechanism.

The XDN platform also provides full support for the multi-profile transcodes used with ABR streaming by utilizing intelligent Edge Node interactions with client devices to deliver content in the profiles appropriate to each user. And to ensure ubiquitous connectivity for every XDN use case, the platform supports content delivery in HTTP Live Streaming (HLS) mode as a fallback. In the rare instances where devices can’t be engaged via any of the other XDN-supported protocols, they will still be able to render the streamed content, albeit with the multi-second latencies that typify HTTP-based streaming.

XDN Nodes can be deployed on multiple cloud infrastructure-as-a-service (IaaS) platforms. This can be done by leveraging pre-integrations with major suppliers like AWS, Google Cloud, Microsoft Azure and DigitalOcean, or through integrations with many other IaaS platforms enabled by Red5 Pro’s use of the Terraform multi-cloud toolset.

XDN Integrations with Cloud Storage Streamline VOD Support via CDNs

It stands to reason that pervasive interactivity tied to live streaming is best served by reliance on an infrastructure purpose-built for this new chapter in online video engagement. But the internet economy will continue to require support for on-demand access to time-shifted live content as well as all the movies and other stored content delivered through SVOD services, social platforms and other outlets.

The challenge, then, is to create an integrated infrastructure environment that recognizes the primacy of real-time interactive streaming for live video while ensuring maximum efficiency in the use of CDN capabilities as needed. Red5 Pro has made this possible through tools that can be used to configure plugins to the AWS S3, Google Cloud Storage, and DigitalOcean Spaces storage services used by Fastly and other CDN operators.

With XDN infrastructure in place to support all use cases involving livestreamed content, service providers can enable VOD availability of that content by leveraging these cloud infrastructures as seamless extensions of their operations. This saves them the time and costs of building and managing separate silos for their livestreamed and VOD services.

Using the XDN Cloudstorage Plugin, service providers with a few simple configuration commands can set up direct connections with these cloud storage services to automate copying of livestreamed content to long-term storage. Once the integrations with supported storage facilities are executed, livestream providers operating over XDN infrastructure can contract with CDN operators to support VOD distribution of their content.

The ability to select optimal solutions for VOD distribution while streamlining the live-to-VOD connection also contributes to minimizing costs. In the case of Fastly, for example, service providers can take advantage of the CDN operator’s Nearline Cache storage for large content libraries to reduce the workloads on origin servers and decrease egress costs.

Additional Time-Shifting Modes Will Be Directly Supported on XDN Infrastructure

In addition to streamlining utilization of leading PaaS resources for VOD services, Red5 Pro will soon be introducing mechanisms instantiated on XDN Edge Nodes to support other time-shift applications, including pause, replay, and start over. As a result, service providers now have a roadmap to the future where they can meet the full range of requirements in the real-time video streaming domain with the storage and distribution support they need to enable all time-shift applications. This puts real-time video-based engagement with livestreamed content where it should be, at the heart of the next generation in media and entertainment services. Visit the HLS server page to get started.

5 Factors in Choosing WebRTC vs HLS

Maria Artamonova — Mon, 26 Oct 2026 05:00:49 +0000

When it comes to choosing WebRTC vs HLS, which protocol delivers the best live streaming experience? Making the correct decision is imperative since the protocol determines how quickly the encoded video data will be transported across an internet connection.

WebRTC is a better choice. If that’s all you wanted to know then feel free to stop reading and go build your live streaming application using WebRTC. However, if you want to know why it is the best choice, and we are betting you do, then read on.

WebRTC vs HLS

There is no universal answer to the question “Which video streaming protocol is better, WebRTC or HLS?” The right choice depends on your use case and project requirements. In modern live streaming workflows, these protocols often work together.

For now, let’s compare WebRTC and HLS in terms of latency, scaling, multi-device compatibility, performance in poor network conditions, and security so you can make an informed decision.”

Latency

The “live” part of live-streaming hinges mostly upon latency. With the exception of VOD-type applications, a large majority of live streaming use cases require a real-time latency of under 500 milliseconds. Anything above that causes a noticeable delay between when the video is captured and when it is seen by a subscriber. Effective live streaming creates interactivity merging the flow between participating in real-world events and experiencing those events in a virtual capacity.

HLS was built on the long established and deeply entrenched HTTP infrastructure leading to the widespread use it currently enjoys. This aging infrastructure is also why HLS results in anywhere from 10-40 seconds of latency.

However, there are ways to modify HLS to decrease the latency. Apple has their own Apple Low Latency HLS (LL-HLS) implementation which is similar to the open-source Low-Latency HLS (LHLS) which both reduce the latency down to around two or three seconds. Though they decrease latency, neither enjoy the widespread compatibility of standard HLS. Furthermore, two to three seconds is still way too high.

Looking to increase the compatibility of LLHLS, in early 2020 Apple announced that it dropped the HTTP/2 push requirement. Thus, it looks like the overall HLS spec will eventually support around 3 seconds of latency. While still not real-time it’s certainly better than 40.

As a UDP based protocol built to fully adapt to the modern internet, WebRTC supports 500ms of real-time latency meaning it is currently the only widely supported protocol that can provide real-time latency.

Scaling

Scaling WebRTC is a little bit harder than HLS. However, that does not mean that it can’t be done especially considering that it has been done.

One such example of successful WebRTC based scaling comes from Microsoft.

In August of 2016 Microsoft acquired Beam, a WebRTC based approach to live game streaming intended to solve the latency issues and provide a better experience over the Twitch platform. A year later, Microsoft changed the name to Mixer. Though they ultimately shut down their Mixer game streaming platform it was due to not being able to attract enough people to it, rather than being able to support a large number of users. The popular gamer Ninja had one stream on Mixer that attracted over 85,000 concurrent viewers and 2.2 million viewers over an 8.5 hour stream.

The initial difficulty in scaling WebRTC stems from the fact that it creates peer-to-peer connections which can consume a great amount of CPU resources. When your hosting provider uses fixed data centers – such as a CDN – meeting that increase means physically adding additional servers or increasing the server capacity. This could be a problem if you hit a higher than anticipated demand, or if you just need a little extra capacity as you could end up paying for a much larger server than you need.

Of course, the main draw to using a CDN in the first place is that the CDN provider will take care of the scaling for you. The problem though, is that CDNs use HTTP to scale, and that comes with a tremendous amount of latency.

This is why you need a clustering solution that works with WebRTC as a protocol. Even better if it can autoscale with cloud infrastructure. This kind of Autoscaling Solution, involves switching from the static, datacenter-based CDN model, to a much more flexible cloud-based model. Server clusters can be set up to dynamically spin up new servers as network traffic increases and spin them back down once they are no longer needed. This alleviates the potential issue of paying for more capacity then you really need.

Red5 Pro’s WebRTC supported Autoscaling Solution works by publishing a stream broadcast to an origin server. Subscribers requesting access to view the broadcast stream, connect to a separate edge server which is then connected to the correct origin server through a stream manager. This architecture allows multiple edges to connect to the same origin server. Thus multiple servers can handle as many connections as needed and all connect to the same broadcasting stream. If the origin hits capacity in the number of edge servers it can connect to, relay nodes allow the origin to connect with several groups of edges. Thus the system will keep spinning up new origins and edges to handle as many publishers and subscribers as needed.

In fact, this dynamic scaling model is similar to how Mixer built their solution. However, Mixer used bare-metal servers which would not be as flexible as a strictly cloud-based solution. If you really want to dive deep into the Red5 Pro approach to cloud based scaling of WebRTC we recommend reading our white paper on the subject.

Multi-Device Compatibility

Ensuring that your application can run on a variety of devices is certainly important. Whether it’s a mobile, laptop or tablet, you need a full complement of browsers and platforms supported.

HLS has native support for mobile browsers (iOS-Safari and Android-Chrome). The only desktop browser with native support is Safari. Everything else requires a custom player implementation written in JavaScript. While there are plenty to choose from including commercial offerings like JWPlayer, there are also open source solutions like hls.js. However, as of today, there are very few players who’ve updated to support the new Low Latency HLS protocol that Apple has introduced.

As a new web-standard, WebRTC is fully supported by the latest versions of all major browsers: Chrome, Safari, Firefox, Edge and Opera. Plus it can be run natively in the browser without the use of a plug-in. That includes mobile browsers as well for iOS and Android. Of course, creating dedicated mobile apps with the use of Mobile SDKs is good too.

Performance in Poor Streaming Conditions

In terms of quality and performance, LL-HLS and WebRTC have similar features as they both can support transcoding and Adaptive Bitrate (ABR).

ABR allows the client to request a lower bitrate that is more appropriate to the connectivity they are experiencing at that moment. That will ensure a smooth connection despite poor connectivity. HLS and it’s newer cousin LL-HLS both have ABR built right into the spec. This is accomplished by a master manifest file which contains the variants. When the player detects that the video isn’t being delivered quickly enough and thus detects insufficient bandwidth, then it can simply request one of the lower stream variants in the manifest. It then starts downloading the new video segments at the lower bitrate.

Understanding the relationship between network capacity and delay is also important for live streaming, so see our guide to bandwidth vs latency.

With WebRTC things are quite a bit different. In WebRTC you have a single UDP connection where the delivery of video is over SRTP. This means you can’t go and make new requests for different segment files since there are no segment files to begin with. Instead the approach is to make available the multiple bitrate variants at the edge server allowing for the client to request the correct quality of video. The request itself is over the RTCP channel, which is a bi-directional control channel for sending live information about the state of each peer in a WebRTC session. The specific message we listen for is REMB which contains the recommended bandwidth that the peer is requesting (in this case the subscriber client). Based on that information, the edge server node can then respond by shifting to delivering the best stream for the bandwidth requirement.

As a side note, both HLS and WebRTC can rely on live transcoding of the streams to generate these multiple bitrate variants. Transcoding splits the stream into a variety of quality ladders (For example: high, medium, and low) so that users who can support the highest quality can subscribe to it, while users with poorer connections can still watch.

While HLS is limited to ABR, WebRTC has additional features further improving quality and performance.

Given that WebRTC is a UDP based protocol, one of its most critical features is NACK, which is a method of resending critical packets. A bad network connection will likely result in the client dropping packets. Rather than trying to resend each and every one of the packets, NACK identifies the ones that are most important and resends those. This prevents the network from getting further overloaded with redundant requests. This will help keep the stream flowing and looking good even under poor network conditions, and doesn’t have the drawbacks of packet backups in TCP based systems. Again, like REMB, NACK is a message type sent over the RTCP channel to the Edge server. The edge server then is responsible for re-delivering that critical packet. WebRTC also supports many other strategies for keeping stream quality high and ensuring efficient delivery of video including FEC, FIR, and PLI, which also happen to work over the RTCP channel.

Security

Making sure that your data and streams remain protected is important as well. Preventing unauthorized users from creating streams and encrypting them so they can’t be intercepted ensures that sensitive information doesn’t leak out.

As mentioned earlier, LL-HLS will be wrapped into the HLS spec. That means that security features available with LL-HLS such as DRM, token authentication, and key rotation will be implemented. However, those extra security features will have to wait until providers can configure them in their systems. Waiting on someone else for your security can be an issue.

HLS does have one prominent security feature in that it can be encrypted. WebRTC is encrypted by default meaning your streams are free from hackers gaining illegal access to your streams. Furthermore, features such as user authentication, file authentication, and round-trip authentication, will further secure your streams.

In regards to DRM systems, for many circumstances the basic security provided by WebRTC is more than enough to protect your data. That means that content owners and distributors can safely forego the costs and hassles of contracting for DRM support if they have the legal latitude to do so.

Conclusion

While it’s clear that WebRTC fosters a better, more interactive, live streaming experience, HLS remains a solid option for streaming; just not live streaming. WebRTC has faster latency, better browser compatibility, and enhanced security features over HLS. While scaling WebRTC can be a little more challenging, that concern is easily surmounted by using a cloud-based autoscaling solution such as Red5 Pro and Red Cloud. Visit our WebRTC server and HLS server pages to get started.

MOQ is also gaining momentum in 2026 as a protocol designed for scalable, high-performance real-time and cached streaming, and many developers hope it will eventually replace the WebRTC plus HLS workflow. We have already launched support for Media over QUIC protocol in Red5 Pro and Red5 Cloud solutions.

CMAF vs WebRTC: Select the Right Delivery Type For Your Use Case

Maria Artamonova — Fri, 23 Oct 2026 05:00:50 +0000

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.

What Is CMAF? Benefits, Limitations, and When to Use It

Maria Artamonova — Thu, 22 Oct 2026 05:00:49 +0000

This guide answers the question “what is CMAF” by explaining how the format works, its benefits and limitations, and when to use it. It also compares CMAF with HLS, WebRTC, DASH, and fMP4.

What is CMAF?

CMAF, or Common Media Application Format, is an open standard for packaging video, audio, and text for adaptive bitrate streaming. It defines a common media container that can be used across modern streaming workflows, helping simplify distribution while improving efficiency.

Rather than introducing a new delivery protocol, CMAF focuses on how media is encoded and segmented so it can be reused across different playback environments. This makes it easier to manage assets, reduce operational overhead, and support scalable streaming on a wide range of devices. CMAF streaming is the delivery of live or on demand media packaged in CMAF containers through compatible protocols such as HLS and MPEG-DASH. CMAF is widely adopted across the streaming industry and serves as a foundation for low latency HTTP streaming when combined with compatible delivery modes and player support.

CMAF Origins: HTTP Live Streaming and HLS Redundancy

HLS and MPEG-DASH are two of the most widely used HTTP-based video streaming protocols for distributing live and on demand content. Delivering an HTTP stream involves dividing the video into small chunks that reside on an HTTP server. In this way, the individual video chunks can be downloaded by a video player via TCP. This allows the video to traverse firewalls easily, where it can be delivered as it is watched, thus minimizing caching.

However, there is a drawback involving the encoding of audio and video data. HLS traditionally uses TS containers to hold the muxed a/v data, while DASH prefers the ISO-Base Media File Format holding demuxed tracks.

In order to connect with a variety of devices, content owners must package and store two sets of files, each holding exactly the same audio and video data. This increases encoding and storage costs because Content Delivery Networks (CDNs) must process and store multiple formats containing the same content.

The creation of the CMAF came out of efforts to solve this redundancy problem. Proposed by Apple and Microsoft in 2016 and standardized by MPEG in 2018, CMAF is a standardized container designed to hold video, audio, or text data that is deployed using HTTP based streaming protocols: HLS or MPEG-DASH.

Bitmovin provides the following definition:

CMAF defines the encoding and packaging of segmented media objects for delivery and decoding on end-user devices in adaptive multimedia presentations. In particular, this is (i) storage, (ii) identification, and (iii) delivery of encoded media objects with various constraints on encoding and packaging. That means CMAF defines not only the segment format but also codecs and most importantly media profiles (i.e., for AVC, HEVC, AAC).

The advantage of the Common Media Application Format is that the same CMAF segments can be referenced by HLS playlists and DASH manifests. CDNs can store one set of files for both video delivery workflows, improving cache efficiency while reducing storage costs.

How CMAF Works

CMAF defines how media is encoded, segmented, and packaged so it can be delivered and decoded consistently across adaptive streaming systems. Content is organized into CMAF Presentations, which contain time-aligned Switching Sets made up of one or more Tracks encoded at different bitrates, resolutions, or qualities. These aligned CMAF Switching Sets support multiple bitrates and allow playback devices to adapt to network conditions without disrupting audio or video continuity.

CMAF media is delivered as addressable objects such as Fragments, Segments, and Chunks, but CMAF itself does not mandate a specific manifest format or delivery protocol. This separation allows the same encoded media to be used with different playback systems while maintaining consistent decoding behavior.

CMAF also supports encrypted media through Common Encryption (CENC), helping compatible workflows accommodate DRM systems such as FairPlay, PlayReady, and Widevine. However, DRM compatibility still depends on the selected encryption scheme, player, platform, and delivery workflow.

For low latency use cases, CMAF supports chunk-based delivery, where fragments are divided into smaller chunks that can be encoded, delivered, and decoded incrementally before a full segment is complete. This enables just-in-time playback while remaining compatible with standard HTTP delivery and CDN workflows.

How Does It Reduce Latency?

In actuality, CMAF containers are not able to reduce latency by themselves. Instead, a low latency mode (known as Low Latency CMAF, or Chunked CMAF) must be configured.

If you can’t tell by now, this is the really technical part so feel free to skip ahead if so inclined.

Chunked CMAF divides each container into smaller sections. Listing them from biggest to smallest: CMAF Container > Segment > Fragment > Chunk. Each chunk is defined as the smallest referenceable unit that contains at least a moof and mdat atom. One or more chunks are combined together to form a fragment which in turn can be merged into a segment.

As an example, if the encoder is producing 4-second segments with 30 frames per second then it would make a POST request to the origin every 4 seconds and each of the 120 frames would be sent using chunked transfer encoding.

What Are the Results?

Laboratory tests with CMAF have achieved end-to-end latencies as low as 600ms. However, results in the real world, away from the lab’s controlled environment, are less impressive. Current proof-of-concepts deployed over the open internet have shown a sustainable Quality of Experience (QoE) only when the end-to-end latency is around 3 seconds.

This increase is due in part to the fact that it requires many small chunks of 250 milliseconds. This would add to the number of HTTP calls happening (at least four per second), create higher bandwidth video, and increase server load; all of which add latency. These trade-offs show why streaming performance depends on both available network capacity and delivery delay; see our guide to bandwidth vs latency.

It should also be noted that CMAF creates problems for consistent stream quality, specifically in regards to adaptive bitrate, because of the way current algorithms estimate throughput.

Is a 3-Second Latency Good Enough for Real-Time?

Definitely not. While CMAF shows improved latency over vanilla HLS and DASH, it is still not low enough to enable fully interactive live video experiences.

As we’ve mentioned before, you can only have real-time streaming if the latency is under 500 milliseconds. In today’s world of instant communication and information, every second (and partial second) counts. Drone surveillance, social media chatting, live auctions, broadcasting live events among many other use-cases, all require real-time latency.

Benefits and Limitations of CMAF

CMAF streaming allows compatible HLS and MPEG-DASH workflows to use the same media files instead of storing separately packaged copies. This simplifies the encoding and delivery process, reduces storage costs, and supports adaptive bitrate delivery across multiple platforms and devices.

Chunked CMAF can also reduce video latency by delivering smaller video segments before a complete segment is available. However, low latency performance depends on compatible encoders, CDNs, players, codecs, and playback devices.

Use CMAF when efficient large-scale video streaming and compatibility with HLS and MPEG-DASH are priorities. For interactive applications requiring sub-second latency, WebRTC or another real-time technology is generally more appropriate. Common CMAF use cases include live sports, news, live commerce, online auctions, and large-scale events where viewers need lower latency but do not require fully interactive communication.

How CMAF Compares to HLS, WebRTC, DASH, and fMP4

CMAF vs HLS

The decision ultimately comes down to compatibility versus efficiency. Choose HLS if you need the broadest possible device support and highly reliable delivery across existing platforms. Choose CMAF if you want to standardize your media format, reduce duplicate encodes, and enable lower-latency HTTP streaming without abandoning HLS delivery. CMAF works alongside HLS, improving how media is packaged while HLS continues to handle distribution and playback.

CMAF should also not be confused with Low-Latency HLS (LL-HLS). CMAF defines how media is packaged, while Low-Latency HLS extends the HLS delivery protocol to reduce latency. Low-Latency HLS commonly uses CMAF-compatible fragmented MP4 segments.

CMAF vs WebRTC

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.

If you want a deeper technical breakdown of latency, scalability, infrastructure requirements, and real-world use cases, read our CMAF vs WebRTC comparison blog.

CMAF vs DASH

The distinction here centers on packaging versus delivery. Choose MPEG-DASH if you need a flexible, standards-based streaming protocol with broad support across platforms and devices. Choose CMAF if you want a single, standardized media format that can be reused across DASH and other HTTP streaming workflows to reduce complexity and storage overhead. CMAF complements DASH by defining how media is packaged, while DASH focuses on how that media is described, delivered, and played back.

CMAF vs fMP4

The difference here lies between a file format and a complete packaging standard. Choose fragmented MP4 if you simply need a container format for segmented media. Choose CMAF if you need a standardized way to package fMP4 with defined constraints that enable interoperability, adaptive switching, and low-latency streaming. CMAF builds on fMP4 by adding rules and profiles that make fragmented media work consistently across streaming platforms and players.

FAQs

What does CMAF stand for?

CMAF stands for Common Media Application Format. It standardizes how video, audio, and text are packaged for adaptive bitrate streaming.

Is CMAF a streaming protocol?

No. CMAF is a media packaging format rather than a streaming protocol. HLS and MPEG-DASH can deliver CMAF-packaged media.

What is the difference between CMAF and HLS?

CMAF defines how media is packaged, while HLS defines how media is described and delivered. HLS playlists can reference CMAF segments.

Does CMAF reduce streaming latency?

CMAF alone does not reduce streaming latency. Chunked CMAF enables lower latency delivery by making encoded chunks available before the complete segment is finished.

What is the difference between CMAF and fMP4?

CMAF uses fragmented MP4 as its underlying container structure but adds media profiles and interoperability requirements for consistent playback across compatible streaming platforms.

Conclusion

When asked what is CMAF, the short answer is that it simplifies how streaming media is packaged and delivered at scale. It improves efficiency and latency compared to traditional HTTP streaming, but it is not intended for fully interactive real-time experiences. For CMAF-based delivery over MOQ (Media over QUIC), the CMAF-Compliant MOQT Streaming Format (CMSF) provides capabilities such as native DRM support, although it typically has higher latency than the Low Overhead Container (LOC). Learn more in “CMSF vs. CMAF: What’s the Difference for Video Streaming?”.

WebRTC Security: Encryption, DTLS, SRTP, and Risks

Maria Artamonova — Wed, 21 Oct 2026 05:00:50 +0000

WebRTC is secure by design at the transport layer: standards-compliant connections encrypt audio and video with SRTP, use DTLS to establish keying material, and protect data channels with DTLS. That does not make an entire WebRTC application secure automatically. User authentication, authorization, signaling, TURN access, server configuration, recordings, application data, and any media processing outside the encrypted connection remain the operator’s responsibility.

This guide explains the WebRTC security architecture, corrects common misconceptions about CORS and end-to-end encryption, and gives developers a practical checklist for protecting real-time communications.

Is WebRTC Secure?

Yes, WebRTC requires encrypted transport for standards-compliant browser connections. Web browsers do not offer an option to send WebRTC media streams as unencrypted RTP. The peers negotiate cryptographic parameters and authenticate the DTLS exchange using certificate fingerprints carried in the session description. Audio and video then travel as encrypted SRTP packets.

That answer needs an important qualification. WebRTC protects traffic between the endpoints of each WebRTC connection. If a media server terminates one connection and creates another, each leg can be encrypted while the server can still access the media in between. This is necessary for many functions, including transcoding, recording, compositing, moderation, and protocol conversion. It is transport encryption, not necessarily end-to-end encryption between the original publisher and every viewer.

WebRTC security therefore has two parts:

Built-in protocol protection: encrypted media, encrypted data channels, and authenticated key establishment.
Application and infrastructure protection: secure signaling, identity, permissions, access control, credential management, server hardening, storage security, monitoring, and incident response.

The protocol supplies a strong foundation. The application still determines who may join, what each user may publish or watch, and what happens to media after it reaches a trusted service.

WebRTC Security Architecture at a Glance

The main security layers are easier to understand when separated by responsibility.

No single row replaces the others. A securely encrypted media connection can still be exposed by a stolen session token, an overly broad authorization rule, a vulnerable signaling service, or a public recording bucket.

How WebRTC Encryption Works

WebRTC establishes a connection in stages. Signaling exchanges descriptions and connectivity information. ICE finds a viable network path. DTLS authenticates the peers and establishes keying material. SRTP protects audio and video, while DTLS protects data-channel traffic.

SDP and Certificate Fingerprints

The Session Description Protocol (SDP) describes media capabilities and connection parameters. An offer and answer can include codecs, media directions, ICE information, and a fingerprint of the certificate that a peer will use during the DTLS handshake. Protecting this key exchange helps prevent man-in-the-middle substitution.

WebRTC does not prescribe how an application exchanges SDP. The application may use HTTPS, secure WebSockets, or another signaling mechanism. Because the certificate fingerprint travels through signaling, an attacker who can alter signaling may be able to substitute connection details. Protecting and authenticating the signaling path is therefore essential even though signaling does not carry the media itself.

DTLS and Key Establishment

DTLS stands for Datagram Transport Layer Security. It provides TLS-style security for datagram transports and is used by WebRTC peers to authenticate the connection and derive keying material. The peers compare the certificate presented during the DTLS handshake with the fingerprint exchanged through SDP.

For media, WebRTC uses the DTLS-SRTP mechanism standardized in RFC 5764. DTLS establishes the material from which SRTP keys are derived. It is more accurate to describe DTLS as a datagram-oriented security protocol based on TLS than as a subset of TLS.

SRTP for Audio and Video

Secure Real-time Transport Protocol, or SRTP, provides confidentiality, message authentication, and replay protection for RTP media. WebRTC uses SRTP for audio and video and SRTCP for the associated control traffic. The encryption is handled by the WebRTC implementation rather than by application JavaScript.

SRTP does not encrypt the signaling service, application API, stored recording, or administrative interface. Those systems need their own controls. SRTP also should not be confused with SRT, the Secure Reliable Transport protocol used in many contribution workflows.

Data-Channel Protection

WebRTC data channels do not use SRTP. They carry SCTP over DTLS, so messages are encrypted in transit between the WebRTC peers. Applications must still validate the content they receive. Treat data-channel messages as untrusted input, enforce authorization, limit message sizes and rates, and never assume that encryption proves a user is allowed to perform an action. The same principle applies to media streams: encryption protects transport, not business permissions.

For a standards-level description of the threat model and security properties, see the IETF’s WebRTC Security Architecture.

HTTPS, Permissions, and Device Access

Browsers restrict camera and microphone access because those media devices expose sensitive information. The getUserMedia() API is available only in a secure context, with limited exceptions such as local development, and requires explicit user consent. The user’s browser also shows indicators while a camera or microphone is in use.

Serve the application over HTTPS with a valid certificate. Request only the devices and capabilities the feature needs, make the request in response to a clear user action, and provide a useful experience when permission is denied. Applications embedded in an iframe also need an appropriate Permissions Policy and iframe configuration before the embedded origin can request access.

HTTPS protects delivery of the application and its calls to HTTPS endpoints. It does not replace WebRTC’s media encryption. The page, signaling channel, and peer connection are separate security layers that work together.

Signaling Security, CORS, and Secure WebSockets

Signaling coordinates a WebRTC session, but signaling is not defined by the WebRTC specification. An application usually exchanges offers, answers, ICE candidates, and session-control messages through an HTTPS API or secure WebSocket connection.

Protect the signaling server or service as carefully as any other authenticated application endpoint:

Use HTTPS or WSS in production.
Authenticate the user before allowing a publish or subscribe action.
Authorize the specific room, stream, and role rather than checking only that the user is signed in.
Use short-lived, narrowly scoped credentials where practical.
Validate signaling messages and reject unexpected state transitions.
Apply rate limits and protect session identifiers against guessing and reuse.
Avoid placing long-lived secrets in client-side code or URLs.

What CORS Does and Does Not Do

Cross-Origin Resource Sharing, or CORS, is a browser mechanism that lets a server state which web origins may read responses to cross-origin requests. It matters when a WebRTC application calls an HTTP API on a different origin. CORS is not a user-authentication system, and an permissive CORS policy does not grant legitimate business authorization by itself.

WebSockets are not governed by the CORS protocol in the same way as fetch() requests. A WebSocket server should validate the Origin header, authenticate the session, and reject origins it does not trust. WSS encrypts the signaling connection in transit, while application authorization decides what that connection may do.

Do not solve cross-origin errors by allowing every origin together with credentials. Maintain an explicit production allowlist and test it whenever domains, CDNs, or application environments change.

ICE, STUN, and TURN Security

Interactive Connectivity Establishment, or ICE, gathers possible network paths and tests candidate pairs until the peers find a working route. Candidates can represent a local interface, an address discovered through STUN, or a relay allocated through TURN.

STUN helps a client learn its server-reflexive address. TURN relays traffic when a direct path cannot be established or when policy requires a relay. TURN is not simply a performance fallback: it is an operational dependency for users behind restrictive NATs and firewalls. Because TURN and WebRTC connections must operate across varying network conditions, understanding the relationship between available bandwidth and delivery delay is also important; see our guide to bandwidth vs latency.

For production deployments:

Operate sufficient TURN capacity in the regions your users need.
Use authenticated, preferably time-limited TURN credentials instead of publishing a permanent shared password.
Restrict allowed transports and relay behavior to the requirements of the application.
Monitor allocation volume, bandwidth, authentication failures, and unusual geographic patterns.
Keep TURN software patched and protect its administrative interfaces.
Test UDP and TCP/TLS relay paths from restrictive networks.

ICE candidates can disclose network information needed to establish connectivity. Applications should avoid logging or exposing candidate data unnecessarily and should apply their normal privacy, retention, and access policies to signaling logs.

What WebRTC Does Not Secure Automatically

WebRTC’s mandatory transport encryption solves an important problem, but it is not a complete application security model.

Identity and Authorization

Encryption protects a connection; it does not decide whether the person on that connection is allowed to publish a stream, enter a private room, control a camera, or view premium content. Map authenticated identities to explicit permissions and enforce those permissions on the server for every sensitive action.

End-to-End Encryption Through Media Servers

A selective forwarding unit, media server, or streaming platform may terminate WebRTC connections. Each client-to-server leg can be encrypted, but the server may access unencrypted media in memory. If the threat model requires the server to be unable to read media, the application needs an additional end-to-end encryption design, compatible clients, key management, and a clear decision about which server-side features must be sacrificed or adapted.

Do not label a service end-to-end encrypted merely because every network hop uses DTLS-SRTP. State the trusted endpoints and where media can be decrypted.

Recordings, Transcoding, and Protocol Conversion

When a platform records, transcodes, composites, analyzes, or converts a WebRTC stream, the media leaves the protection boundary of the original peer connection inside a trusted service. Protect resulting files and intermediate data with encryption at rest, strict access control, retention limits, audit logs, and secure deletion procedures.

Application and Supply-Chain Risks

Cross-site scripting can let malicious code operate with the privileges of the application. Vulnerable dependencies, leaked tokens, weak APIs, exposed dashboards, and insecure cloud storage can undermine an otherwise correct WebRTC connection. Use a Content Security Policy, dependency and container scanning, secure secret storage, timely patching, least-privilege service accounts, and regular security testing.

Metadata and Privacy

Encryption does not hide every fact about a session. Participants and infrastructure may still observe IP addresses, timing, traffic volume, device characteristics, account data, and operational logs. Collect only what the service needs, disclose the purpose, limit retention, and protect access to analytics and support tooling.

How Red5 Fits Into a Secure WebRTC Workflow

Red5 provides live streaming solutions for developers, startups, and enterprises that need to publish, route, and play real-time video. Red5 Cloud is the managed platform option, while Red5 Pro gives teams more control over a self-managed deployment. Both can participate as WebRTC peers in a media workflow and connect browser publishers or subscribers to a larger streaming pipeline.

In this architecture, a browser establishes an encrypted WebRTC connection to a Red5 endpoint. Red5 can then route the stream, create subscriber connections, or perform enabled server-side functions. Each WebRTC leg is protected, but Red5 is a trusted media endpoint rather than an invisible end-to-end-encrypted pass-through. That distinction matters when a workflow includes recording, transcoding, analytics, protocol conversion, or other processing.

Red5 simplifies WebRTC transport and streaming orchestration, but application owners still need to configure HTTPS and secure signaling, authenticate users, authorize publish and subscribe operations, protect TURN credentials, restrict administrative access, patch infrastructure, and secure stored media. Teams using Red5 Pro should follow the current SSL configuration documentation for their deployment. Teams using Red5 Cloud should apply the identity, token, and application controls documented for the managed service.

The open-source Red5 Media Server is a separate product and does not provide the WebRTC capabilities described in this section. Use Red5 Cloud or Red5 Pro when the workflow requires supported WebRTC publishing and playback.

WebRTC Security Checklist

Use this checklist before production launch and repeat it after meaningful architecture or dependency changes.

Serve every production page and API endpoint over HTTPS with valid, monitored certificates.
Use WSS or another authenticated, encrypted signaling transport.
Validate signaling origins and messages; do not treat CORS as authentication.
Require authentication and enforce stream-, room-, and role-level authorization on the server.
Use short-lived, scoped session and TURN credentials where practical.
Provide TURN capacity and test relay paths from restrictive networks.
Keep media servers, TURN servers, dependencies, operating systems, and containers patched.
Restrict administrative interfaces by network and identity, with strong multifactor authentication where supported.
Protect recordings, thumbnails, transcripts, logs, and analytics data at rest and in transit.
Apply rate limits, abuse controls, input validation, and monitoring to signaling and data channels.
Decide whether transport encryption is sufficient or true end-to-end encryption is required.
Document trusted endpoints, media-processing boundaries, data retention, and incident procedures.
Test permission-denied paths, expired credentials, revoked users, certificate renewal, and TURN failure.
Run security reviews and penetration tests that cover the application, not only the WebRTC transport.

FAQs

Is WebRTC encrypted by default?

WebRTC requires encrypted transport for standards-compliant connections. Audio and video use SRTP with keying material established through DTLS-SRTP, while data channels use SCTP over DTLS. This protects traffic between the endpoints of each peer connection, but it does not automatically protect recordings, signaling data, application APIs, or media inside a trusted server.

Is WebRTC end-to-end encrypted?

WebRTC is encrypted between the endpoints of each peer connection. In a direct peer-to-peer call, those endpoints may be the users’ devices. When a media server terminates separate connections, every leg may be encrypted while the server can access the media. True end-to-end encryption requires an additional design that keeps keys away from the server.

What is the difference between DTLS and SRTP in WebRTC?

DTLS authenticates the WebRTC peers and establishes keying material. SRTP uses derived keys to protect real-time audio and video, including confidentiality, integrity, and replay protection. Data channels follow a different path: SCTP messages are protected directly by DTLS rather than by SRTP.

Does WebRTC require HTTPS?

Browser camera and microphone access through getUserMedia()\ generally requires a secure context, so production applications should be served over HTTPS. Secure delivery also protects the application’s code and HTTPS APIs. HTTPS does not carry the WebRTC media itself; the peer connection uses its own DTLS, SRTP, and ICE mechanisms.

Are STUN and TURN secure?

STUN and TURN are connectivity tools, not complete application-security systems. TURN can authenticate allocations and can operate over protected transports, but operators must secure credentials, patch the service, restrict abuse, and monitor bandwidth. Use time-limited credentials and test the relay paths required by your users and networks.

Does CORS secure a WebRTC application?

No. CORS controls whether browser JavaScript from one origin can read certain cross-origin HTTP responses. It does not authenticate users or authorize access to a stream. A secure WebRTC application also needs protected signaling, origin validation, authentication, server-side authorization, input validation, rate limits, and secure infrastructure.

Conclusion

WebRTC security starts with strong mandatory transport protection. DTLS-SRTP encrypts audio and video, DTLS protects data channels, and browser secure-context rules help protect device access. Those controls make WebRTC a solid basis for real-time communications, but they do not secure the full application on their own.

Build the rest of the system around that foundation: protect signaling, verify identity, enforce authorization, secure STUN and TURN operations, harden media infrastructure, and define what happens wherever media is decrypted or stored. If you are building a WebRTC streaming application and need help designing a secure, scalable workflow, contact Red5.

WebRTC vs RTMP: Which Protocol Should You Use?

Maria Artamonova — Tue, 20 Oct 2026 11:10:37 +0000

WebRTC vs RTMP is not always an either-or decision. RTMP and its encrypted variant, RTMPS, remain practical choices for sending video from encoders such as OBS Studio to a media server. WebRTC is generally the better fit when viewers or participants need interactive, real-time video in a browser or mobile application.

Many live streaming applications therefore use both: RTMP or RTMPS for contribution and WebRTC for delivery. The right architecture depends on who publishes the stream, where it must play, how much interaction the experience requires, and how the system will scale.

WebRTC vs RTMP at a Glance

If you need a quick rule, use WebRTC when the audience must see and respond to video in real time. Use RTMP or RTMPS when an existing encoder needs a widely supported way to publish a stream. Use both when your contribution and playback requirements differ.

What Is RTMP?

RTMP stands for Real-Time Messaging Protocol. It was originally developed for communication between Flash Player and a server, but its current value is different. Although modern browsers do not natively play RTMP streams, the protocol remains widely used as an ingest protocol for live video.

Software encoders such as OBS Studio and many hardware encoders can publish to an RTMP endpoint. A media server or streaming platform receives that feed and then converts, packages, or redistributes it for viewers through another protocol.

RTMP uses TCP, which delivers bytes reliably and in order. When packets are lost, retransmission can delay subsequent data. That behavior can be useful for maintaining an intact contribution feed, but it is less suited to highly interactive playback on variable networks than a real-time media stack designed to adapt around delay and loss.

The security distinction matters:

rtmp:// does not encrypt the connection.
rtmps:// carries RTMP over TLS and should be preferred whenever the publisher and destination support it.

RTMP is therefore not obsolete, but its role has narrowed. It remains useful between encoders and ingest servers rather than as a modern browser-delivery protocol. For a deeper explanation, read What Is RTMP Streaming?.

What Is WebRTC?

WebRTC stands for Web Real-Time Communication. It is a collection of browser APIs and real-time protocols for sending audio, video, and application data between compatible endpoints. The W3C WebRTC Recommendation defines the browser-facing API, while related IETF standards define the protocols used underneath it.

WebRTC is available in current major browsers and gives web applications controlled access to cameras and microphones. It is built for real-time communication and includes mandatory encryption for media transport. This makes it suitable for experiences in which delay directly affects the conversation or action, such as video conferencing, live auctions, interactive sports, remote control, and audience participation.

Establishing a WebRTC connection is more involved than entering a server URL and stream key. Interactive Connectivity Establishment (ICE) determines how endpoints can communicate across firewalls and Network Address Translation. It can use STUN to discover reachable addresses and TURN to relay traffic when a direct path cannot be established. The MDN introduction to WebRTC protocols explains these components in more detail.

WebRTC is often described as peer-to-peer, but production applications do not have to connect every participant directly to every other participant. Multi-party and large-scale systems commonly introduce media servers such as Selective Forwarding Units (SFUs) to route streams efficiently and adapt delivery to different devices and network conditions.

Key Differences Between WebRTC and RTMP

Latency and Network Behavior

WebRTC is designed around real-time interaction. Its media transport, congestion control, jitter handling, and feedback mechanisms prioritize keeping a session responsive as network conditions change. Packet loss can reduce momentary quality without necessarily forcing all later media to wait.

RTMP sends data over TCP. TCP retransmits missing data and preserves delivery order, so a loss event can add delay while later data waits. Actual glass-to-glass latency still depends on the complete workflow, including encoding, buffering, server processing, transcoding, network distance, and player behavior. The protocol alone does not guarantee a specific latency.

For a one-way contribution feed from a controlled encoder, RTMP can be entirely appropriate. For a participant who must react to live video, WebRTC usually provides the more suitable delivery path.

Browser and Encoder Compatibility

WebRTC is integrated into current major browsers and supports browser-based capture and playback without a plug-in. That is a major change from the early browser landscape described in the original version of this article.

RTMP no longer plays natively in modern browsers, but it retains broad support across live production tools. OBS Studio, hardware encoders, cameras, and established broadcast workflows often provide RTMP or RTMPS publishing. This makes RTMP a convenient bridge from existing contribution equipment into a newer delivery stack.

The endpoint requirements should drive the choice:

If a presenter publishes from a browser or mobile application, WebRTC can handle capture and contribution.
If a production team publishes from OBS or a hardware encoder, RTMP or RTMPS may require less integration work.
If viewers watch in a browser and need real-time interaction, deliver with WebRTC even when the source arrives through RTMP.

Security

WebRTC requires secure media transport. Implementations use DTLS to establish keys and SRTP to protect real-time audio and video. Applications still need their own authentication, authorization, session controls, and secure signaling, but unencrypted WebRTC media is not a normal deployment option.

Basic RTMP provides no transport encryption. RTMPS adds TLS protection between the publisher and ingest endpoint. This protects the connection in transit, but it does not replace application-level access controls or determine how the stream is protected after ingest.

Comparing “secure WebRTC” with unencrypted RTMP can therefore be misleading. A practical security review should compare the complete deployments, including whether RTMPS is enabled, how keys and tokens are managed, who can publish or subscribe, and where media is decrypted or transformed.

Scaling and Architecture

Neither protocol solves audience scaling by itself. WebRTC can establish a direct connection between endpoints, but direct peer meshes become inefficient as each participant must send media to more peers. Production systems typically use SFUs, media servers, regional infrastructure, or other routing architectures.

RTMP is usually only the first leg of a one-to-many workflow. The receiving platform must replicate, transcode, or repackage the stream and deliver it through WebRTC, HLS, or another playback protocol. Scaling therefore depends on the media infrastructure around the protocol, not simply on choosing RTMP.

Adaptive bitrate delivery also requires more than a protocol name. A service may create multiple renditions, use simulcast or scalable video coding, and select an appropriate version for each viewer. The available approach depends on the publisher, codecs, server, player, and delivery architecture.

When Should You Use WebRTC?

Choose WebRTC when the experience depends on immediate communication or control. Common examples include:

Video conferencing and group communication
Live commerce and auctions where reactions affect the event
Interactive sports, betting, and second-screen experiences
Remote production, robotics, drones, and device control
Telehealth, customer support, and expert assistance
Browser or mobile publishing without a separate encoder
Real-time data synchronized with audio and video

WebRTC is not automatically the simplest option. You must plan signaling, ICE, STUN and TURN services, browser permissions, media routing, codec compatibility, adaptive delivery, and observability. A commercial platform or managed service can remove much of that infrastructure work.

When Should You Use RTMP or RTMPS?

Use RTMP or preferably RTMPS when you need to accept a feed from tools that already support it. It remains a strong option for:

Publishing from OBS Studio or another software encoder
Connecting hardware encoders and existing production equipment
Sending a contribution feed to a streaming platform
Preserving compatibility with established live production workflows
Migrating an ingest workflow without replacing every publisher at once

Do not choose RTMP as the final browser playback protocol. Instead, terminate the RTMP connection at a media server and deliver the stream in a format supported by the target player and use case.

When Should You Use WebRTC and RTMP Together?

A combined architecture is often the most practical answer to WebRTC vs RTMP. It allows existing encoders to keep publishing through RTMP or RTMPS while viewers receive the stream through WebRTC.

A typical path looks like this:

The reverse direction can also be useful. A browser or mobile application can publish with WebRTC, while the platform converts or redistributes that content for destinations that expect RTMP. Protocol interoperability lets each endpoint use a suitable interface without forcing the entire system onto one transport.

Using WebRTC and RTMP With Red5

Red5 products are live streaming solutions for developers, startups, and enterprises that need to build protocol workflows into an application rather than simply stream to a social platform.

Red5 Cloud is the easier managed option. It provides hosted streaming infrastructure and is appropriate when a team wants to start quickly without operating its own server deployment. The Red5 Cloud RTMP quick-start guide shows how to create an endpoint, publish an RTMP feed, and play the stream.

Red5 Pro is the advanced self-managed option for teams that need greater control over deployment, infrastructure, customization, and integrations. Its documentation includes instructions for publishing from third-party RTMP and RTSP encoders.

Both approaches let a development team design around endpoint requirements rather than declare one universal protocol winner. An encoder can contribute through RTMP while an interactive application uses WebRTC for delivery, or compatible clients can publish and subscribe through WebRTC throughout the workflow.

FAQs

Is WebRTC faster than RTMP?

WebRTC is generally better suited to interactive, real-time delivery, but no protocol guarantees a fixed glass-to-glass latency. Encoding, buffering, server processing, network conditions, geographic distance, and player behavior all affect the result.

Is RTMP obsolete?

RTMP is obsolete for native playback in modern browsers, but it remains widely used for contribution from software and hardware encoders. Use RTMPS when the publisher and server support it so the ingest connection is encrypted.

Can WebRTC and RTMP be used together?

Yes. A common workflow accepts RTMP or RTMPS from an encoder and delivers the stream to viewers through WebRTC. A media server bridges the protocols and handles authentication, routing, and any necessary media processing.

Should I use WebRTC or RTMP with OBS Studio?

RTMP or RTMPS is usually the straightforward choice because OBS and many streaming destinations support it directly. If a destination provides a tested WebRTC publishing integration, that may also be an option, but follow the destination’s current setup documentation.

Conclusion

The WebRTC vs RTMP decision depends on the endpoints and the experience you are building. WebRTC is the stronger fit for interactive browser and application communication. RTMP and RTMPS remain useful for contribution from OBS, hardware encoders, and established production systems.

For many live streaming applications, the best answer is to use both: RTMP or RTMPS for compatible ingest and WebRTC for real-time delivery. A media platform that supports protocol interoperability can connect those stages while letting developers choose managed infrastructure through Red5 Cloud or a self-managed deployment with Red5 Pro.

H.266 vs AV1 for Live Streaming: What Codec to Choose

Maria Artamonova — Thu, 08 Oct 2026 05:00:17 +0000

H.266 vs AV1 is a choice between potential compression gains and ecosystem readiness. H.266, also called Versatile Video Coding (VVC), is designed for demanding video applications, including ultra-high-definition and immersive media. AV1 is generally the more practical option for internet-facing streaming when an open specification, current browser support, and broader implementation availability matter.

The better codec depends on the complete workflow: encoding speed, hardware acceleration, target devices, licensing, protocols, latency requirements, storage, delivery cost, and fallback support. This guide compares H.266 vs. AV1 for developers and streaming engineers without declaring one universal winner.

H.266 vs. AV1: The Short Answer

Choose AV1 first for modern web delivery, bandwidth-sensitive streaming, and audiences using newer browsers and devices.
Evaluate H.266 for controlled-device, high-resolution, immersive, or future-focused deployments where compatible encoders and decoders can be guaranteed.
Use multiple codecs when the audience includes both modern and legacy devices. Capability detection and fallbacks are safer than assuming universal support.

What Developers Are Using in 2026

Recent production data shows a much larger adoption gap between AV1 and H.266/VVC than their status as two next-generation codecs might suggest. NETINT’s 2026 State of Video Encoding survey found AV1 in production at 17% of responding organizations, with another 40% planning deployment in 2026, bringing its combined production and planned reach to 57%. H.266/VVC was in production at just 4%, although 29% planned deployment, for a combined reach of 33%. The survey describes AV1 as moving from early-adopter experimentation toward mainstream deployment, while VVC remains largely in the evaluation stage. State-of-Video-Encoding-Report

The barriers are also different. Hardware decode support remains a challenge for both codecs, cited by 54% for AV1 and 59% for VVC. AV1 respondents reported more concern about toolchain limitations and encoding compute costs, while VVC faced a much larger licensing barrier: 44% cited licensing or royalties for VVC compared with less than 1% for AV1. The data supports AV1 as the more mature deployment choice today, while H.266/VVC is attracting meaningful interest but still faces ecosystem and licensing hurdles before broader production adoption.

What Are H.266/VVC and AV1?

H.266/VVC is an international video coding standard developed through the Joint Video Experts Team of ITU-T and ISO/IEC. VVC expands the coding tools available for applications ranging from conventional video to UHD, high dynamic range, 360-degree, and immersive content.

AV1 is an open video codec developed by the Alliance for Open Media. It targets efficient video delivery across internet, broadcast, storage, and real-time applications. A video codec defines how video is compressed and decompressed; it is not the same thing as a streaming protocol.

H.266 vs. AV1 Comparison Table

Compression Efficiency and Video Quality

The main reason to evaluate either codec is to reduce bitrate at a target visual quality. Lower bitrate can reduce origin traffic, CDN delivery, storage requirements, and the bandwidth required by viewers. The actual result depends on the encoder, preset, content, resolution, frame rate, color format, and quality metric.

Do not apply a single compression percentage to every workflow. Sports, animation, screen content, film grain, and low-light footage create different encoding challenges. A fair comparison uses the same source and comparable settings, measures objective quality with tools such as VMAF or SSIM, and includes visual review.

Encoding Complexity and Hardware Support

Higher compression efficiency can require more computation. That trade-off is easier to accept for offline video on demand than for live video, where every frame must be encoded before its playback deadline.

AV1 encoding and decoding are available in newer hardware platforms, although the supported profiles, resolutions, and real-time performance vary. H.266 implementations and hardware are less widely deployed. Teams evaluating either codec should verify the exact processor, accelerator, driver, SDK, profile, resolution, frame rate, and rate-control mode.

Browser and Device Compatibility

Compatibility is often the deciding factor for internet video. AV1 playback is available in major current browsers, but support can still depend on the operating system and hardware decoder. Older devices may use more CPU, consume more battery, or require a fallback.

H.266 playback is not yet as broadly available across ordinary browsers and consumer devices. It may be more practical in controlled environments where the organization manages the encoder, decoder, player, and endpoint hardware. Browser playback support also does not prove that a browser can capture or publish the codec efficiently.

Licensing and Operational Cost

AV1 was published as a royalty-free specification. H.266/VVC is associated with patent licensing programs whose obligations can vary by product, implementation, distribution model, and territory. Development teams should obtain legal advice for their exact use case rather than treating either label as a complete licensing analysis.

Licensing is only one part of codec cost. Model encoder capacity, hardware acceleration, storage, bandwidth, transcoding, monitoring, and fallback renditions together. A codec that reduces delivery bitrate but substantially increases real-time compute may not reduce the total operating cost.

H.266 vs. AV1 for Live Streaming

For live streaming, the codec must work across the complete glass-to-glass path. The encoder must meet its frame deadline, the media server must accept or process the stream, the transport must carry it, and the player must decode it without excessive buffering.

The codec does not determine latency by itself. GOP structure, rate control, transcoding, network conditions, the transport protocol, adaptive bitrate logic, buffering, and player behavior all contribute to end-to-end streaming latency.

AV1 is generally the more practical codec to evaluate first for internet-facing streaming when the audience uses modern browsers and devices. H.266 is worth testing when endpoints are controlled or when specialized high-resolution and immersive workloads justify the additional ecosystem constraints.

Which Codec Should You Choose?

Choose AV1 when:

Your audience primarily uses current browsers and newer devices.
Bandwidth, storage, or delivery cost is a major constraint.
An open, royalty-free specification is important to the product strategy.
You can maintain an appropriate fallback for unsupported endpoints.

Evaluate H.266 when:

You control the playback devices and software.
UHD, immersive, or specialized delivery justifies testing a newer codec.
You can source compatible encoders, decoders, players, and monitoring tools.
You are prepared to operate fallback or transcoding paths.

How to Test H.266 vs. AV1

Select representative content, including motion, fine detail, graphics, and low-light scenes.
Encode both codecs at matched quality targets and equivalent resolution, frame rate, and color format.
Measure bitrate, visual quality, encoding delay, CPU or GPU use, memory, and cost.
Test decoding on the actual browser, phone, television, and managed-device mix.
Test the full ingest-to-player workflow, including recording, transcoding, adaptive bitrate, and fallback behavior.

FAQs

Is H.266 better than AV1?

Not universally. H.266 may be attractive for specialized high-resolution or immersive workflows, while AV1 currently offers a more practical ecosystem for many internet-facing applications. Test both with representative content and endpoints.

Which codec is better for live streaming?

AV1 is generally the more practical starting point for modern internet delivery. H.266 can make sense when an organization controls its encoders and playback devices or has specialized efficiency requirements.

Does H.266 reduce streaming latency?

No codec guarantees lower end-to-end latency. Encoding settings, GOP structure, transcoding, transport, network conditions, buffering, adaptive bitrate behavior, and the player all influence latency.

Conclusion

H.266 vs AV1 is a trade-off between potential compression efficiency and ecosystem readiness. AV1 is usually the safer codec to evaluate first for internet-facing live streaming, while H.266 deserves targeted testing for controlled, high-resolution, immersive, or future-focused deployments. Benchmark the complete workflow and keep a fallback plan before making either codec part of a production architecture.