DEV Community: Maria Artamonova

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.

The MOQ Shot Heard Around the World After IBC 2026

Maria Artamonova — Thu, 01 Oct 2026 05:00:15 +0000

Introduction

IBC 2026 left no doubt that it’s now off to the races for the new MOQ streaming standard as the M&E industry confirms the platform achieves the cost-saving efficiencies and expanded functionalities everyone involved in live streaming is looking for.

The transformative impact of real-time interactive streaming as enabled by MOQ remains key to what lies ahead, but right now it’s the streaming industry’s urgent need to escape the cost/functionality crunch imposed by conventional streaming that’s top of mind. As was evident everywhere we turned at IBC, the do-more-for-less combination with unlimited scalability, personalized feature and advertising flexibility, support for interactive data and video applications, and multiple latency options readily implemented on a single standardized platform is what has sealed the case for market-wide acceleration into MOQ-based streaming.

Widely acknowledged proof of what MOQ can do follows months of beta testing by service providers at global scales over our partner CacheFly’s global CDN and other MOQ-equipped CDNs operated by Cloudflare, CDN77, Vindral, Broadpeak, Netskrt and others. Especially notable at IBC was the fact that these results have spurred cloud compute giants Oracle OCI, Amazon AWS and Akamai to declare they’re all in with MOQ, with more likely to follow.

MOQ demos were in abundance, by one count tripling the total last year. Critically, any uncertainty about the platform’s support for real-time interactive streaming in a multi-device environment was put to rest in a live game-playing competition Red5 staged for attendees at CacheFly’s stand. This and the Red5 MOQ content-protection and provenance-verification demo running at the EZDRM stand were among several MOQ demos we described in this pre-show blog.

As we met with major players across the streaming ecosystem, we were glad to learn the idea of making MOQ readily available with other streaming protocols in a multi-cloud and CDN environment has taken hold as the best way to bring next-gen streaming to life. This was fitting at an event where, apart from streaming, a major theme was vendors’ adoption of standardized interfaces that allow their customers to deploy competing products with seamless interchangeably in production workflows.

Commercializing MOQ

The prospects for massive transition to MOQ streaming are greatly enhanced by the fact that all of us who package end-to-end support for MOQ at the software-defined media layer will be able to compete at global scales employing cloud infrastructures as merited by business goals, even as suppliers of those infrastructures might be mounting their own managed MOQ streaming services. The same holds in instances where platform suppliers are making it easier for providers to seamlessly shift across MOQ and legacy streaming modes from a single platform.

But it’s also important to note that much of this remains aspirational in terms of commercial execution by the suppliers of MOQ streaming infrastructure. This stuff is hard to master, which is why Oracle, Amazon, Akamai and others say they won’t be ready for commercial MOQ operations until the April 2027 NAB timeframe.

In one manifestation of the challenges, a developer heading up demo preparations from one major newcomer to the market told us about the difficulties he encountered preparing what was shown at IBC, which failed to achieve latency below 1 second or the real-time interactivity that was originally planned as part of the demo. But these things are clearly doable, which, as we said at the outset, is why MOQ is now taking off in preparations for widescale commercial rollouts, in most cases by next spring.

An exception to that timeframe is Red5. We’re pleased to report that these capabilities will be available for commercial operations on Red5’s MOQ-optimized multi-protocol platform by the end of this year, no matter when remaining spec details are finalized by the Internet Engineering Task Force (IETF). Our beta operations utilizing the latest versions of MOQ Transport (MOQT) demonstrate we have all we need to move ahead commercially.

Under the Hood at IBC

A First in Demonstrated MOQ Streaming Interactivity

Before we drill down on why this is the case, we want to share as much of what we experienced at IBC as we can without violating conversational privacy. We turn first to the Ms. Pac Man inspired game we created for IBC with Open Broadcast Software (OBS) capture and FFMPEG media processing support from our OpenMOQ Consortium co-member Qualabs. The cloud-hosted game projected onto the playing screen at the stand allowed two competing players’ inputs to be transmitted to the cloud and returned for real-time display as if the game were hosted locally.

To the best of our knowledge, this was the first time MOQ’s real-time interactive video capabilities were demonstrated publicly. Critically, moving MOQ interactivity to mass-market adoption is now possible without the need for device plug-ins in cases where newer-generation smartphones and other devices are running browsers supporting WebTransport APIs, which allow browsers to handle the underlying transport layer natively by exposing low-latency QUIC streams and datagrams directly to Web applications.

But there’s a caveat. Absent the echo and other noise cancellations essential to videoconferencing which are not yet part of MOQT specs, MOQ-based real-time video interactivity doesn’t supplant the video conferencing use case for WebRTC, which we’ve made seamlessly available for use with MOQ through our TrueTime MeetingsTM toolset.

Nonetheless, synchronized real-time video interactivity across MOQ streams does open the door to the multitude of commercial opportunities for streamers who want to support mass social video engagement with their services. Applications like multiplayer gaming, sports micro-betting and virtual casino gambling, live shopping, auctions and much else, including variations involving extended reality (XR) technologies, will be readily at hand for any entity choosing Red5 or others who can support such interactivity over their MOQ platforms.

Hyperscalers’ MOQ Strategies

Much of what we learned from leading players on both the supply and user sides of the MOQ evolution in discussion at our demo site and elsewhere, including the canal cruise we co-sponsored with our interactive data intelligence partner PubNub, added to our understanding of what’s transpiring with the industry’s transition to MOQ. Much of this, including new partnerships we’re forging with CDN operators, hyperscalers, software vendors and streaming providers, we’ll be bringing to light in the months ahead.

But what we can share now as important examples of what’s in store in the emerging MOQ coopetition market are some aspects to the strategies Oracle, Amazon and Akamai have landed on for next year. These developments augment what we’ve already reported about industry activities, including the many agendas we covered in our post-NAB 2026 blog.

Oracle

In Oracle’s case, after some internal debate under a mandate from chairman and co-founder Larry Ellison to put MOQ front and center in a new focus on the M&E industry, as described in this report, OCI executives decided to take an open-market multi-protocol approach, which they hope to bring to market by next April at NAB 2027. They anticipate their backing for MOQ will help to induce encoding, CDN and other vendors into shaping products that will accelerate market adoption of the new standard in a multi-infrastructure environment.

At the same time, they’re creating a turnkey end-to-end multiprotocol managed streaming service that will be marketed in competition with other users of OCI infrastructure like Red5. Some of this came to light in an IBC Showcase session describing how Paramount, led by Ellison’s son David Ellison, and CDN operator Netskrt had worked with Oracle to build an end-to-end MOQ pipeline leveraging OCI’s Oracle Video Edge (OVE) to connect to Netskrt end points for delivery to end users.

AWS

Plans at AWS are still in flux as to what level of turnkey service support will be provided for users of its cloud infrastructure for MOQ streaming. But, with a commercial rollout timeframe similar to Oracle’s, the goal is to work with partners to ensure the AWS cloud is fully operational for end-to-end MOQ streaming. Pending further discussions, it remains to be seen what role Red5, already deeply engaged with both of these hyperscalers, will play in their new MOQ-related strategies.

Akamai

As for Akamai, the company is focused on providing a global MOQT environment that leverages its deep-edge presence as an alternative to traditional hyperscaling, which appears to be the direction OCI is taking with its OVE agenda. As Akamai explained in a recent blog, its edge-based strategy is motivated by the AI market’s move beyond training to inference where AI agent processing should be as close to their use cases as possible to enable them to perform dedicated tasks at lightning speed.

Not only does this aid in latency reduction when MOQ relays are deployed to make use of those edge resources. It also makes AI-targeted GPU resources that are sometimes needed in advanced streaming applications more readily available as alternatives to the commonly used CPU resources.

The Red5 MOQ Commercialization Timeframe

People may wonder why, if most of the MOQ platform market, including these hyperscalers, have set spring 2027 as the target for commercial operations, Red5 is able to implement its multi-protocol approach to streaming with both full end-to-end MOQ managed service and DIY support as soon as specifications are frozen, which, again, we expect to happen by year’s end. This is significant because it means live-streaming service providers who want to capitalize on MOQ will have a three-to-four-month lead over competitors who choose other approaches.

The two-pronged answer to why our early timeframe is achievable lies with what we’re doing at both the transport and the media layers of the MOQ protocol stacks, which has to do with the versatility of our Experience Delivery Network (XDN) Architecture and the open-software knowhow we’ve been able to apply.

Player and C Library Templates

One important aspect to our work with software involves development of two key Open MOQ Consortium-endorsed building blocks, including:

Playa, the MOQ Type S cript library . Playa is a versatile TypeScript library endorsed by the Open MOQ Consortium as a way developers can build client applications primarily targeted for browser implementations, whether for devices used at the publishing end or for end-user playback, with assurance that their software stacks will be in complete compliance with MOQ specifications.

As described in this blog, anyone who follows the prescriptions for using readily available open software components as laid out in the Playa specs can build a browser-supported end-user client player that delivers the full playback benefits of MOQ streaming on devices of every kind. At the same time, Playa can be used in the publishing process to equip hardware used at every step from live capture through all the workstations in a localized or dispersed production workflow. For example, to create the interactive MOQ game demo described earlier we used Playa in conjunction with Chrome to capture and encode the real-time dynamics for output to people playing at the show.

From a MOQ media layer perspective, Playa dovetails with the IETF’s emerging specifications for three versions of MOQ Streaming Formats: CMSF, where the C signals the fact that’s it’s meant exclusively for use with the Common Media Application Format (CMAF); LOC, the low-overhead, encoded and encrypted A/V container format, and the emerging LOCMAF format, which combines the best of the other formats’ techniques. All these IETF-specified formats define how the streamed A/V and ancillary elements conveying captioning, personalized and commonly shared features and ads, and other applications are compressed, encrypted and packaged.

A unique MOQT-compliant open-source native C library known as MOQ5, which, like Playa, is being adopted by the Open MOQ Consortium as another template that can foster accelerated MOQ implementation across the streaming ecosystem. As described at greater length here, MOQ5 provides an open-protocol foundation focused on session state, message encoding and decoding, subscription management, track and object handling, protocol negotiation and transport-independent logic. This gives developers a flexible foundation for integrating MOQT into different products and runtime environments independently of any particular network stack.

Exclusive Software Components

In addition to these open software templates, there are many proprietary elements to what we’re making available with MOQ in the software domain.

One important new product along these lines is the Red5 Video Packager, which, as described in this white paper, provides a software stack supporting all the transcoding and packaging requirements embodied in MOQ, HTTP and WebRTC streaming protocols. A universal packager, of course, is essential to enabling any streaming provider’s support for all these highly divergent streaming modes in a single managed service.

Red5 customers streaming over MOQ will also have access to the application versatility encompassed in our TrueTimeTM toolsets. Along with the aforementioned TrueTime MeetingsTM, these include TrueTime MultiView™, TrueTime WatchPartyTM, TrueTime Datasync™, and TrueTime StudioTM. As with everything else we’re doing with MOQ, these tools can be applied at the MOQ beta stage and in forthcoming commercial services with the managed MOQ service provided through Red5 Cloud or in customers’ self-managed MOQ deployments they build using our Red5 Pro SDKs.

The Importance of Networking Knowhow

Open availability of the Red5 Playa universal player and the MOQ5 C-library template can help everyone get over the hump to commercialization of MOQ streaming, but there’s still a lot of work to be done at the networking level, where orchestrating cloud resources to maximize speed and efficiency across the MOQ relay footprint, let alone getting those resources to dance on command to the tunes emanating from a multi-protocol streaming platform, is a major challenge.

This brings us to the network orchestration component of the XDN Architecture that underlies our ability to bring MOQ streaming to market sooner than later. With MOQ we’re utilizing the capabilities of our Stream Manager, which has made it possible for customers worldwide to achieve end-to-end 250ms latencies over WebRTC at interactive streaming scales reaching into the millions of users – something that even today some naysayers contend can’t be done. Much of the documentation on our website, including this account, describes how this is done and the many use cases we’re supporting with the Red5 Cloud managed service and customer implementations of self-managed XDN infrastructures with the aid of our Red5 Pro SDKs.

As we said two years ago when we first decided to back MOQ, even though we had automated implementation of WebRTC streaming with the Red5 Cloud service, we were making the move to MOQ while supporting WebRTC full stop because MOQ provides a universally standardized approach to streaming with tiered latency options and other advantages that are fundamental to meeting live streamers’ goals of doing more for less.

As we explain in our What is MOQ blog, this is a connectionless mode of streaming that avoids the complexity and error-prone request-response method used with HTTP streaming. Encapsulating independently manageable application tracks within each payload, MOQ streams reach end users through a system of cloud relay nodes that allow any given stream to be fanned out from a single source to any number of end users with minimal use of processing resources. At the same time, MOQ relays provide short-segment caching support that allows latecomers to access a stream in sync with other users, and they optionally enable live content recording for short-term replay and catchup.

The XDN Stream Manager’s support for MOQ applies a multitude of benefits customers have long experienced with our networking infrastructure, including end-to-end latency reductions stemming from our approaches to using cloud resources for transcoding and other processing, multi-transport protocol ingestion into and egress from MOQ relays, multi-stream compositing that can consolidate synchronized feeds in mass numbers from users participating in interactive applications, and much else.

Adding to the MOQ deployment versatility we support through Red5 Cloud and Red5 Pro, we’re introducing support for private MOQ-optimized CDN configurations with release of the Red5 MOQ Relays into that domain. This allows anyone running their own infrastructure and data centers to deploy a MOQ based CDN using our licensed software

Moreover, to extend our cloud resource orchestration capabilities into the legacy HTTP streaming domain we’ve introduced Version 2 of the Stream Manager, which works in tandem with the universal Red5 Video Packager. This makes it possible in cases where XDN Architecture supports MOQ streaming over CDNs optimized for MOQ to switch to HLS or DASH just as use of the XDN enables seamless activation of real-time streaming over WebRTC.

In the case of HTTP-based live and on-demand streaming, when a stream is ingested onto an origin node, the Stream Manager sends a request to the Video Packager to begin transcoding. The Video Packager pulls the stream, generates HLS or DASH segments and uploads the packaged payload to one of the output destinations configured to work with the Packager, which currently includes cloud-based distribution and storage platforms supported by AWS, GCI, Azure, OCI, Linode and Digital Ocean.

Conclusion

That the streaming industry has reached the point of transition to next-generation operations over MOQ in so short a time from its beginning as a proposed IETF standard is nothing short of amazing. The excitement over the prospects for what this means to how people engage with the internet was palpable everywhere we turned at IBC.

The spotlight on MOQ will grow ever more intense in conferences, webinars and trade publication reports over the months ahead. And we’ll be doing all we can in public appearances and our postings to keep the world up to date on fast-moving developments.

As we said earlier, one of the great advancements with preparations for MOQ streaming has been the commitment of ever more platform providers to streamlining operations in a multi-stream-mode environment. It remains to be seen how all these plans will play out, but, as we’ve explained here, streamers can be assured they’ll have this kind of versatility and the attendant cost savings when they opt to implement MOQ over Red5 infrastructure.

Meanwhile, to learn more about our technology, plans and how to prepare for what’s ahead, reach out to our team by email or schedule a call.

5G Live Streaming: Benefits, Challenges, and How It Works

Maria Artamonova — Mon, 21 Sep 2026 05:00:17 +0000

5G live streaming gives broadcasters, event producers, enterprises, and public agencies a more flexible way to send live video from locations where fixed connectivity is limited or unavailable. Its higher capacity and lower-latency potential can make remote production, mobile contribution, and interactive viewing easier, but a 5G connection alone does not guarantee a reliable real-time stream.

To understand where 5G delivers real value, it helps to examine the entire path from the camera to the viewer. Network coverage is only one part of that path. Encoding, transport protocols, edge computing, stream processing, scaling, playback, and contingency planning all affect the final experience.

What Is 5G Live Streaming?

5G live streaming is the capture, transmission, processing, and delivery of live video using a fifth-generation mobile network somewhere in the workflow. Depending on the application, 5G may carry an uplink from a field camera to a production platform, deliver a downlink from that platform to viewers, or support both directions in an interactive experience.

This definition matters because “5G streaming” can describe several very different activities. A consumer watching a conventional video service over a 5G phone is not using the same workflow as a broadcaster sending multiple camera feeds from a stadium to a remote control room. The first is primarily content distribution. The second is live contribution and production, where continuity, latency, synchronization, and return communications may be mission-critical.

3GPP TS 26.501 defines the general architecture for 5G Media Streaming, including network and application functions for downlink and uplink media services. That standards work provides a framework for closer coordination between mobile networks and media applications.

How 5G Live Streaming Works from Camera to Viewer

A professional 5G workflow usually contains more technology than the mobile network itself. The video must be captured, compressed, moved through one or more networks, processed by a streaming platform, and delivered in a form the viewer’s device can play.

1. Capture and encoding

A camera, smartphone, drone, or other video source captures the event. An encoder compresses the raw signal into a practical bitrate and packages it for transport. The encoder may be built into the camera or phone, attached as a separate mobile transmitter, or operated as software on a nearby device.

The encoding decisions affect picture quality, bandwidth consumption, and delay. Higher resolutions and frame rates require more data, while aggressive compression may reduce bandwidth at the cost of processing time or visible artifacts.

2. 5G uplink and contribution

The encoded feed travels over the 5G uplink to a production facility, cloud platform, or edge location. This stage is often called contribution. In the field, a production team may use one mobile connection, a private 5G network, or bonded connectivity that combines several cellular links and other available paths.

Bonding is still valuable in a 5G environment because radio conditions can change. People move, vehicles block signals, cells become congested, and devices switch between coverage areas. A resilient design can adapt the bitrate or move traffic across alternate connections instead of treating one 5G signal as an infallible circuit.

3. Edge or cloud processing

The incoming feed may need to be routed, transcoded into multiple renditions, mixed with other feeds, recorded, analyzed, or synchronized with data. Placing some of this processing closer to the mobile network can reduce the distance packets travel before reaching the application.

AWS Wavelength, for example, places cloud compute and storage services in telecommunications providers’ data centers. AWS identifies video production among the latency-sensitive applications that can benefit from this edge infrastructure. This is an access-and-compute advantage, not a guarantee of a particular glass-to-glass latency, because encoding, processing, transport, and playback still contribute delay.

4. Stream distribution

After processing, the platform distributes the stream to its intended audience. A one-way program may be delivered through HTTP-based streaming when reach and device compatibility matter more than immediate interaction. A live auction, remote collaboration session, synchronized sports experience, or command-and-control application may need a real-time protocol and infrastructure designed to preserve very low latency at scale.

Red5 Pro and Red5 Cloud support sub-250 millisecond streaming targets for real-time applications. Actual glass-to-glass latency still depends on the complete workflow, network conditions, deployment, and endpoint configuration.

5. Playback and interaction

The final stream reaches a browser, mobile application, television, operations center, or another endpoint. In an interactive use case, video may travel in more than one direction while synchronized data carries chat, telemetry, control messages, scores, or other event information.

The viewer’s experience therefore depends on the slowest or least reliable part of the complete path. Strong 5G performance at the camera cannot compensate for an overloaded processing layer, an inefficient delivery architecture, or a player with a large buffer.

The Benefits of 5G Live Streaming

More freedom at the point of capture

5G can reduce dependence on fixed fiber drops, satellite trucks, and extensive temporary cabling. Crews can send video from moving vehicles, crowded venues, remote worksites, and locations where installing a dedicated circuit would be slow or impractical.

That mobility can expand the kinds of events an organization can cover. It can also enable additional camera positions, rapid deployment, and live reporting from locations that would otherwise be limited to recorded footage.

Greater support for remote production

When camera feeds can reach a production team with adequate quality and predictable delay, more switching, graphics, audio, and editorial work can happen off-site. The GSMA’s media production work documents the industry’s use of 5G for mobile live contribution and remote production.

Remote production can reduce the equipment and personnel that must travel to every venue. It can also allow centralized specialists to support several events from one facility. The business benefit is not simply faster connectivity. It is a more flexible operating model.

A shorter path to edge applications

5G edge computing can place processing closer to capture devices and viewers. That can help with time-sensitive operations such as return video, multi-camera coordination, live graphics, computer vision, and interactive event experiences. For a deeper technical perspective, read our analysis of the emerging 5G streaming architecture and its implications for content providers.

Red5 has previously explored this model through its work on real-time video streaming over 5G and AWS Wavelength Zones. The architectural objective is to eliminate avoidable internet hops before a stream enters the processing and distribution layer.

Better support for high-value interactive experiences

The most important advantage is not necessarily a higher-resolution picture. It is the ability to build experiences in which the video remains closely synchronized with the live event and its data.

For example, an in-venue sports application might combine alternate camera angles, live statistics, audience participation, or wagering information. Red5 describes these possibilities in its article on 5G in-venue experiences and its more recent overview of real-time in-stadium streaming.

New options for private production networks

A private 5G network can give a venue, broadcaster, manufacturer, university, or public agency more control over local coverage, device policy, and capacity than a best-effort public connection. The degree of traffic separation and performance control depends on the private-network design, spectrum arrangement, and integration with the wider workflow.

Private 5G does not remove the need for careful application design. The stream still has to leave the local radio network, enter processing infrastructure, and reach its destination. However, it can make the first network segment more predictable.

Why 5G Does Not Automatically Guarantee a Reliable Stream

The marketing language around 5G often compresses a complex system into a promise of speed. Professional streaming teams need a more cautious standard: can the complete workflow maintain the required quality, delay, and continuity under real operating conditions?

Coverage and capacity are not the same

A device may display a 5G indicator without having the sustained uplink capacity needed for a high-quality live feed. Available performance varies by spectrum, cell configuration, device, location, competing traffic, and operator policy.

This is particularly important at stadiums, festivals, breaking-news locations, and public events. The moment that makes the video valuable may also be the moment when thousands of nearby users place the greatest demand on the network.

Uplink performance deserves special attention

Consumer speed discussions often emphasize downloads, but contribution workflows depend on uploads. A production team should test sustained uplink throughput, packet loss, jitter, handoffs, and recovery behavior along the actual route and at the expected event time.

Testing should also reflect the intended production settings. A brief phone speed test cannot substitute for sending the target resolution and bitrate over a realistic period while the device or camera is moving.

Low network latency is not glass-to-glass latency

Network latency measures only part of the experience. Glass-to-glass latency includes capture, encoding, network transport, processing, distribution, player buffering, and display. A fast radio link can coexist with a delayed video workflow.

This distinction is why the streaming platform and protocol still matter. Red5’s explanation of ultra-low latency streaming examines how application requirements should determine whether a few seconds, sub-second delivery, or real-time performance is appropriate.

Network slicing and quality APIs are still developing commercially

Network slicing can create logically separated service environments with different performance characteristics on shared 5G infrastructure. In principle, this can help protect critical production traffic from ordinary congestion.

Access is not yet uniform across operators and markets. In 2026, broadcast organizations working with the GSMA called for standardized Quality on Demand APIs that would let production teams request predictable network treatment for critical video, audio, and control flows. That GSMA industry statement shows both the promise of network-aware production and the work still required to make it broadly accessible.

Security must cover the full workflow

Live feeds may carry licensed programming, private operational video, health information, or public-safety data. Appropriate protections can include encrypted transport, authenticated publishing, access control, key management, secure application interfaces, monitoring, and content protection at playback.

The mobile link is only one security boundary. Cameras, encoders, edge applications, cloud accounts, streaming servers, APIs, and players must all be included in the threat model.

Public 5G, Private 5G, or Bonded Cellular?

There is no universal connectivity design for every live production. The right choice depends on geography, mobility, event value, available spectrum, operational control, and the consequences of failure.

A useful decision rule is to design around the business impact of an interruption. A low-risk social stream may work well over one public 5G connection. A national broadcast, emergency operation, or paid interactive event should use multiple layers of resilience.

5G Live Streaming Use Cases

Live sports and venue experiences: 5G can support roaming cameras, remote production, feeds from difficult camera positions, and video delivered to spectators inside a venue. When paired with real-time streaming and synchronized data, it can also power alternate views, statistics, watch parties, and other interactive features.
News and field reporting: Reporters and camera operators can contribute from locations that lack fixed production infrastructure. Smaller field teams can begin coverage quickly, while centralized production staff handle switching, graphics, and distribution.
Remote monitoring and public safety: Drones, body-worn cameras, vehicles, and fixed cameras can send live video to operations centers. These use cases place particular emphasis on security, many-to-one stream management, situational latency, and continuity during movement.
Industrial and enterprise video: Organizations can use mobile live video for remote inspections, expert assistance, training, robotics, and site monitoring. A private 5G network may be especially relevant when operations take place repeatedly within a controlled facility.
Live events and mobile creators: Concerts, conferences, houses of worship, and independent producers can use 5G to simplify contribution or add cameras without running new cable. Professional results still depend on the encoding, audio, lighting, redundancy, and delivery platform surrounding that connection.

How Red5 Completes the 5G Live Streaming Workflow

5G provides mobile network access between a device and network-connected infrastructure. Red5 addresses the application and delivery work that begins once a live feed is ready to be processed and shared.

Red5 Pro is self-managed server infrastructure that teams can deploy on premises or in their chosen cloud.
Red5 Cloud is a fully managed platform with global autoscaling.

Both are designed for real-time streaming, while actual latency and capacity depend on the end-to-end design and operating conditions.

Protocol flexibility is important in mixed production environments. Red5 Pro documents support for RTSP, RTMP, SRT, WebRTC, HLS, and other streaming protocols, allowing teams to use different transports for contribution and delivery where appropriate. Red5’s discussion of SRT and real-time streaming explains how contribution workflows can connect to real-time distribution without forcing every endpoint to use the same transport.

Beyond transport, Red5 Cloud documents capabilities including transcoding, recording, global autoscaling, frame-accurate metadata synchronization, encryption, authentication, APIs, webhooks, and SDKs. Red5 Pro adds control over deployment and infrastructure for teams that need to operate the streaming stack themselves. These capabilities allow teams to treat 5G as one part of a production and experience-delivery strategy rather than as a complete streaming solution by itself.

A Practical 5G Live Streaming Checklist

Before taking a 5G production live, teams should answer the following questions:

What is the required resolution, frame rate, and sustained contribution bitrate?
Is the uplink tested at the actual location, time, and expected crowd density?
Will the camera move between cells or remain in one coverage area?
What happens when bandwidth falls below the target bitrate?
Is there an independent backup path?
Where will encoding, transcoding, mixing, recording, and analysis occur?
Which protocol is best for each stage of contribution and distribution?
What is the acceptable glass-to-glass latency for the use case?
How many simultaneous publishers and viewers must the platform support?
How will publishing, playback, APIs, and stored content be protected?
What metrics will the team monitor during the event?
Has the complete workflow been tested under realistic failure conditions?

Conclusion

5G live streaming can make professional video production more mobile, flexible, and responsive. It can reduce reliance on fixed connections, bring cloud and edge processing closer to the point of capture, and enable new real-time experiences for sports, news, public safety, enterprise operations, and live events.

Its benefits are strongest when 5G is treated as one component of an end-to-end system. Reliable production still requires appropriate encoding, resilient contribution, efficient processing, scalable distribution, secure access, and playback designed for the application’s latency target.

Red5 brings those pieces together with real-time, multi-protocol streaming infrastructure that can connect mobile contribution workflows to interactive experiences and audiences at scale. Contact the Red5 team to discuss how your 5G live video workflow can be designed for the latency, reliability, security, and reach your application requires.

RTMP vs SRT: Which Ingest Protocol Should You Use?

Maria Artamonova — Sun, 20 Sep 2026 05:00:13 +0000

The practical RTMP vs SRT choice comes down to compatibility and network conditions. Use RTMP or RTMPS when you need the simplest path from a widely supported encoder to a streaming platform. Use SRT when both endpoints support it and the contribution feed must cross a lossy, unstable, or long-distance network.

Neither protocol is normally the final delivery format for viewers in a modern browser. Both are commonly used to send live video into a media server or streaming platform, which can then process and deliver the stream through WebRTC, HLS, DASH, MOQ (Media over QUIC), or another protocol suited to the audience.

RTMP vs SRT at a Glance

The strongest production design may support both. RTMP can provide a familiar publishing path for creators and legacy equipment, while SRT can protect higher-value feeds crossing difficult networks.

What Is RTMP?

RTMP stands for Real-Time Messaging Protocol. Adobe originally developed it to move audio, video, and data between Flash applications and a server. Flash playback disappeared from modern browsers, but RTMP remains common as an ingest protocol.

Its continued use is easy to understand. A broadcaster can enter an RTMP server URL and stream key into software such as OBS Studio or a compatible hardware encoder and begin publishing. Many streaming platforms and media servers already understand this workflow.

RTMP runs over TCP. TCP guarantees ordered delivery and retransmits lost data. That reliability is useful, but retransmission can make later data wait behind a missing packet. On a stable connection, the behavior may be acceptable. When delay, jitter, or packet loss increases, the stream can stall or accumulate latency because TCP prioritizes complete ordered delivery.

The protocol name also does not tell you whether the connection is encrypted:

RTMP uses an unencrypted connection.
RTMPS carries RTMP over TLS and protects the connection between the encoder and ingest server.

Use RTMPS when both endpoints support it. Encryption in transit does not replace publisher authentication, stream authorization, credential protection, or other application security controls. Learn more about the protocol in What Is RTMP Streaming?.

What Is SRT?

SRT stands for Secure Reliable Transport. It is an open-source transport protocol initiated by Haivision for reliable, low-latency transmission across unpredictable networks. SRT runs over UDP but adds timing, congestion-control, and loss-recovery mechanisms designed for live media contribution.

SRT uses acknowledgments and Automatic Repeat Request (ARQ) to identify and selectively retransmit lost packets. Unlike a basic UDP stream, it can recover data that would otherwise be missing. Unlike TCP, it is designed to manage packet recovery within a configured latency budget rather than provide an indefinitely ordered byte stream.

The receiver holds packets in a configurable latency buffer. A larger buffer gives retransmitted packets more time to arrive, improving resilience at the cost of additional delay. A smaller value reduces delay but leaves less time to recover losses. SRT latency is therefore a tuning decision, not a universal sub-second guarantee.

SRT also supports AES payload encryption. It is enabled by configuring compatible passphrases at both endpoints. Calling SRT “secure by default” would be inaccurate because encryption must be configured and key management still matters.

The protocol is described in an expired individual IETF Internet-Draft, which has no formal standing as an IETF standard. The active open-source implementation and project documentation remain the practical references for deployed SRT behavior.

Key Differences Between RTMP and SRT

Reliability on Unpredictable Networks

SRT was designed for contribution feeds that travel across the public internet, cellular connections, or long-distance routes where packet loss, jitter, and changing bandwidth are expected. Its receiver reports lost packets so the sender can retransmit selected data while the configured latency buffer determines how long recovery can continue.

RTMP relies on TCP for reliability. TCP works well on many stable paths, but packet loss can trigger retransmission and head-of-line blocking. A missing segment can delay subsequent media even if those later packets already arrived. The impact depends on the round-trip time, loss pattern, congestion, bitrate, and buffering across the full pipeline.

This does not mean SRT always produces a better stream. If the bitrate exceeds available bandwidth for too long, no transport can preserve every packet without increasing delay or dropping data. SRT must also be configured with realistic bandwidth overhead and latency values for the actual path.

Latency

Protocol comparisons often claim that SRT has lower latency than RTMP, but that statement is too broad. SRT adds an explicit latency buffer to support retransmission. RTMP can also operate with relatively low contribution latency on a stable local or regional connection.

SRT’s advantage is controllable resilience. Operators can choose a latency value that allows recovery across a measured network path. The required buffer should account for round-trip time and the expected severity of packet loss. Increasing it can improve reliability but also increases contribution end-to-end latency.

Measure glass-to-glass latency rather than inferring it from the ingest protocol. Encoding, frame structure, transcoding, media-server processing, delivery protocol, player buffers, and device performance can contribute more delay than the contribution leg.

Security

Basic RTMP does not encrypt the connection. RTMPS protects RTMP traffic with TLS, so it should be the relevant comparison when security is required.

SRT can encrypt its payload with AES when a passphrase is configured. It also offers stream identifiers that applications can use during connection setup, but the surrounding platform must still authenticate users and authorize publishing or playback.

For either protocol, protect credentials, restrict ingest endpoints, rotate secrets, monitor connection attempts, and verify how decrypted media is handled after it reaches the server.

Codec and Payload Support

RTMP is a media-specific protocol created around older Flash-era workflows. Its established implementations commonly use H.264 video and AAC audio, which remain broadly interoperable. Supporting newer codecs or different media structures can require extensions or another transport.

SRT is a transport protocol rather than a codec or player format. Live video workflows commonly carry MPEG Transport Stream over SRT, allowing the payload to contain combinations of video, audio, captions, and metadata supported by the two endpoints.

SRT transport support does not automatically guarantee codec compatibility. The sender, receiver, transcoder, and final player must still agree on the payload format and codecs.

Encoder and Platform Compatibility

RTMP remains the compatibility choice. It is available in many software encoders, hardware appliances, and streaming platforms, so it often requires less setup and fewer infrastructure changes.

SRT has broad adoption in professional media tools, but support is not universal. Check the exact encoder model, firmware, software build, receiver, connection mode, and supported SRT parameters. A platform that accepts RTMP cannot receive an SRT stream unless it exposes a separate SRT ingest endpoint.

Firewall behavior also differs. RTMP uses TCP, while SRT uses UDP ports selected by the deployment. Confirm that the required outbound and inbound traffic is permitted along the complete route.

When Should You Use RTMP or RTMPS?

Choose RTMP or RTMPS when:

Your encoder or destination does not support SRT.
You need a straightforward setup for OBS Studio or another familiar publishing tool.
The contribution path is stable and packet loss is low.
You must integrate with established creator, social, or production workflows.
Operational simplicity matters more than advanced recovery controls.

Prefer RTMPS over unencrypted RTMP whenever it is supported. Before going live, test the real bitrate, path, reconnect behavior, credential handling, and end-to-end playback rather than assuming broad compatibility guarantees a reliable production stream.

When Should You Use SRT?

Choose SRT when:

A valuable contribution feed crosses the public internet between facilities or cloud regions.
Remote production depends on cellular, Wi-Fi, or other variable connectivity.
Packet loss and jitter are realistic operational risks.
You need to tune the balance between latency and retransmission time.
Both endpoints support the required SRT mode, encryption, payload, and parameters.

SRT is particularly useful for field contribution, remote production, contribution to the cloud, and links between processing locations. It is not automatically the right delivery protocol for a general web audience, and it should not be selected merely because UDP sounds faster than TCP.

Can You Use RTMP and SRT Together?

Yes. A media server can accept different ingest protocols and convert, route, or repackage streams for later stages. One workflow might accept RTMP from creators while using SRT for a contribution feed between a venue and cloud infrastructure.

A mixed workflow can look like this:

This approach avoids forcing one protocol onto every endpoint. It also lets teams migrate high-risk contribution paths to SRT while preserving RTMP compatibility for existing publishers.

Using RTMP and SRT With Red5

Red5 Cloud and Red5 Pro support multiple streaming protocols, including RTMP and SRT. Red5 Cloud is the managed option for teams that want Red5 to operate the streaming infrastructure. Red5 Pro is the self-managed option for organizations that need greater deployment and infrastructure control.

The Red5 Cloud RTMP guide walks through publishing from OBS Studio. A separate Red5 Cloud SRT guide explains how to create an SRT stream and configure an SRT encoder.

Developers can use protocol interoperability to match each contribution source with an appropriate ingest path, then deliver through a protocol suited to the audience. Review the current Red5 streaming protocol documentation for supported workflows before finalizing an implementation.

FAQs

Is SRT better than RTMP?

SRT is generally better suited to lossy or unpredictable contribution networks. RTMP or RTMPS is often easier when broad encoder and platform compatibility matters most. The better choice depends on the network, endpoints, security configuration, and operational requirements.

Is SRT always lower latency than RTMP?

No. SRT uses a configurable latency buffer to create time for packet recovery. A larger buffer improves resilience but adds delay. Compare complete tested workflows because encoding, server processing, delivery, and playback also affect glass-to-glass latency.

Does SRT include encryption?

SRT supports AES payload encryption when a passphrase is configured at compatible endpoints. Encryption is not automatically enabled simply because the protocol is named Secure Reliable Transport. Authentication, authorization, and credential management remain separate responsibilities.

Can OBS Studio stream with SRT?

OBS support can depend on the installed version, operating system, build options, output method, and destination requirements. Verify the current OBS documentation and test the exact workflow. RTMP or RTMPS remains the more familiar native publishing path for many OBS users.

Conclusion

The RTMP vs SRT decision is not about declaring one universal winner. RTMP and RTMPS provide broad compatibility and a familiar ingest workflow. SRT provides configurable loss recovery, timing, and encryption features for contribution across unpredictable networks.

Use RTMPS for a straightforward encoder-to-platform connection on a stable path. Use SRT when both endpoints support it and the feed must tolerate packet loss, jitter, or long-distance public internet transport. Support both when different publishers and contribution routes have different needs.

Escalating Battle against AI Deepfakes Mandates Smart Streaming Decisions

Maria Artamonova — Sat, 19 Sep 2026 05:00:09 +0000

Introduction

As providers of streamed content open next-gen streaming gateways to real-time, higher quality and more immersive user engagement, they need to make sure they’re deploying streaming platforms best suited to countering the intensifying AI deepfake scourge.

AI-driven fakery at unprecedented levels of verisimilitude in just about every use case category involving internet transmission of static images and A/V content has become a big money maker on the Dark Web. Purveyors of deception are generating payback by:

executing fraudulent financial transactions using AI to create fakes that bypass facial and voice authentication systems,
inserting faux online meeting presences to eavesdrop on enterprises and government agencies,
blackmailing people with highly realistic distortions of reality, including puerile depictions of children and adults,
manipulating political outcomes through fake ads and newscasts,
undermining companies’ standing with investors and the public by putting false words in the mouths of executives,
and much else.

There’s also growing use of deepfake technology by people engaged in self-promotional deception targeted to enhancing personal stature in art, e-commerce, scientific research and other career pursuits. On the auditory side, AI is now generating fully produced music productions that are topping pop music charts. And as reported by at least one trade publication, there’s even a growing acceptance of public deception among some TV broadcasters who see no harm in using AI to lip-sync on-air personalities for delivery of live commentary in different languages over sister outlets.

High-performing deepfake tools are abundantly available, often at prices and usage simplicity that put them in reach of just about anyone. Users can generate videos directly from text using replications of real people sampled from photos, create YouTube how-to videos from documents, replace people and distort scenes in existing videos.

Some deepfake platforms go so far as to eliminate the need for dedicated computing hardware by performing most of the processing in the cloud. But even the top-performing deepfake tools offered at higher prices reaching hundreds of dollars monthly present no barriers to tech-savvy users who are positioned to generate high ROIs on those outlays.

In light of these trends, combatting AI fakery has moved to the strategic front burner wherever the reliability of content being what it’s claimed to be matters, which is to say, just about everywhere. The multi-billion-dollar question is, what can be done to stem the tide?

With reality benders and defenders generating tit-for-tat AI-fueled tech advances at breakneck speed, expert opinion is neutral on the question of whether the anti-fake battle can be won with technology alone, especially in laissez-faire regulatory environments that prevail in the U.S. and elsewhere. But it’s clear that the best chances for success will lie with streamers who can rely on next-gen streaming platforms that optimize use of the tools at hand, whether they’re designed to detect fakes or to provide validation of provenance legitimacy.

In the discussion that follows we explain how Red 5’s support for next-gen streaming provides the framework providers need to maximize effectiveness of whatever approaches they take to combatting AI fakes. As shall be seen, whether our Experience Delivery Network (XDN) Architecture is used in deployments involving streaming via the new MOQ Transport standard, WebRTC or legacy Hypertext Transfer Protocol (HTTP) based platforms, it provides the edge-based intelligence essential to timely execution of anti-fake solutions, facilitated by our open-source API approach to integration with those solutions and our unique high-speed live-stream video frame extraction process.

But before getting into those details, it’s worth taking a look at where things stand in the use of fakes and anti-fake technologies. Research reports from numerous sources lump static image and video fakes together in painting a disturbing picture of disruptions to societal norms on multiple fronts against a backdrop of lagging industry commitment to remedial action.

Generally speaking, anti-fake tools apply in all circumstances but face bigger challenges to effectiveness when hackers target live A/V streams. This is where the capabilities of XDN-based streaming platforms are especially significant.

The Deepfake and Deterrence Landscape

The Ascending Assault Vector

Given the exponential pace of the fake surge, researchers acknowledge there’s no way to track the volume of deepfake instances transpiring across the globe other than through projections based on samplings and surveys. But all such endeavors point to skyrocketing rates of deception and fraud worldwide.

For example, Reuters has cited research from deepfake detection supplier Deep Media that projected the number of deepfake files shared over the internet would jump from 500,000 in 2023 to eight million in 2025. “This sheer scale combined with greater sophistication and convincingness means finding ways to quickly detect and mitigate this ever-growing threat is an increasingly urgent priority,” Reuters reported.

Separately, a 2025 press release from the Reuters Institute for the Study of Journalism reported results from a global consumer survey that found 74% of adults worldwide said they were encountering misinformation in news reports at least weekly. News-related deepfake tracking by detection supplier Resemble that focused on news outlets with an aggregate reach totaling 292.2 billion potential views in the first half of 2026 reported there were 821 deepfake attacks on the 1,760 news reports that were tracked during that timeframe.

Looking at the deepfake impact from the enterprise perspective, research reported by Gartner in fall 2025 found that 62% of recently surveyed organizations had experienced at least one deepfake attack in the previous 12 months. Gartner projects that by 2027 hackers leveraging AI agents will halve the time they need to execute account takeovers with more automated steps aimed at defeating the deepfake kill chain, including use of “deepfake voices to make social engineering more convincing” and new ways to compromise authentication channels.

Recent research conducted by IRONSCALES, another detection supplier, found the deepfake incidence rate to be even higher with 85% of surveyed IT and cybersecurity professionals reporting at least one deepfake attack over the previous year and 40% reporting attack rates at three or above. Over half of the attack victims said they’d lost money from the incidents, with 61% reporting losses of $100,000 or more over that timeframe, 19% registering losses of $500,000 or more, and 5% putting the totals at $1 million or more.

Deepfake Deterrence Moves to the Global Front Burner

Alarm over the deepfake threat has fueled significant increases in cybersecurity budgets and a corresponding surge in suppliers devoted to supplying effective deterrents. Gartner predicts that by next year, 50% of enterprises will be investing in disinformation security products and strategies, up from less than 5% in 2025.

According to a U.K. government report, the number of entities addressing this demand with new deepfake detection solutions as of 2025 had jumped from just a handful in 2017 to 59 worldwide, led by the U.S. with 23 providers and the U.K. with 7. Investment funding averaging $34 million per startup as reported by the U.K. attests to the scale of the impact AI deepfake attacks are having on the global marketplace.

That’s an especially remarkable rate of capitalization in light of the hurdles to profitability faced by all these players. According to the U.K. report, projected ROIs are low for the those who survive owing to concerns over high technical costs, resource constraints, detection reliability, vulnerability to manipulation and variability in metrics and testing datasets.

Arguably, in contrast to deepfake detection, the approach with the broadest range of participation from streamers and suppliers alike involves validating the identity of the original sources, i.e., the provenance, of streamed and posted content as formulated through the Content Authenticity Initiative (CAI) undertaken by the 6,000-member Coalition for Content Provenance and Authenticity (C2PA).

C2PA Provenance Validation

C2PA establishes a common approach to registering and tracking content provenance identity based on data or assertions listing who created the asset, when it was created, the devices and software used, whether AI was involved, what edits such as cropping or color adjustment were applied in production, and other information, including new categories of assertions C2PA groups might want to add to the specifications over time. All of this is compiled in a manifest file that’s cryptographically tied to the content wherever it goes.

The system uses a C2PA tool to compute a hash in the form of a compact invisible forensic fingerprint or watermark and signs the manifest using a private key backed by a digital certificate that ties the content to the originating device and software. That signing is what makes the credentials trustworthy, insofar as any time someone alters the pixels or the recorded provenance, the match to the stored hatch is broken. The specifications also allow for legitimate downstream editing of the content with new manifests created by C2PA tools chained to the original through the signing process.

Pluses & Minuses in C2PA Support

As noted in a blog posted at the beginning of 2026 by senior CAI director Andy Parsons, C2PA moved into widescale deployment last year and has been rapidly gaining support ever since with the latest version of the specifications now supporting provenance verification with live-streamed video in real time. “Entering year six, we are no longer just defining principles and goals,” Parsons wrote. “We are seeing interoperable provenance take shape in the real world.”

A big boost to adoption was provided in late 2025 when Adobe, which, along with Intel, The New York Times, Twitter, Arm, BBC, Truepic and Microsoft, founded C2PA in 2021, introduced what it calls Content Authenticity for Enterprise to operationalize provenance verification in the production process. This provides an automated means by which brands using Adobe’s production tools can integrate provenance into custom workflows, digital asset management platforms and publishing systems, eliminating the need to apply C2PA on a per-project basis. (Adobe arch competitor Avid is also a member contributing to C2PA development but, as far as we know, has yet to take a similar step toward streamlining use of the technology.)

Adding to the momentum, as reported by C2PA applications supplier Lumethic, a large number of leading suppliers of video and photo cameras, smartphones and camcorders have automated registration of C2PA credentials at the point of capture. And providers of streaming platforms such as Amsterdam-based Unified Streaming are introducing support for C2PA by attaching certified source credentials in the pre-distribution packaging phase.

There are now two organizations devoted to ensuring consistency in the use of C2PA specifications:

The Creator Assertions Working Group (CAWG) serves to standardize C2PA specifications for use by professional content creators, develop new modes of identity assertion, and help creators test their conformance to the standards.
JPEG Trust is an initiative within the ISO’s JPEG ecosystem that defines how provenance information is annotated, extracted, evaluated and secured over the lifetime of JPEG media in conformity with ISO’s Content Credential standard, which is built on the C2PA specifications.

But with all this growing support on the credential registration side, the absence of equally broad support for detecting C2PA provenance validation on the receive end remains a serious drawback to effective protection against deepfake deception. It’s a classic chicken-and-egg situation where, until there’s more pervasive use of C2PA credentials in content creation, spending on technology that looks for needles in the haystack may not make much sense to many market players.

Nonetheless, recent progress in that direction offers some hope for a brighter outlook over time. For example, Google has added C2PA credential detection into its “About this Image” feature, which executes with a right click on any image opened in Chrome, and there are C2PA credential detection apps available in app stores that can be activated to work in various browsers.

But, given the sparse use of C2PA on the creator side, the credential detection apps more often than not generate a message in the C2PA space that says C2PA is not used with the chosen image. In cases where C2PA has been used by the content generator, clicking on the confirmation message will open the C2PA manifest to reveal all the identifying data.

It doesn’t appear that similar capabilities have been activated in browsers for C2PA credential detection in videos. But users do have the ability to search for C2PA credentials by clicking on a CAI link that takes them to a site where they can upload or paste the URL of any image, video or document. It takes about 30 seconds for the CAI tool to check for and display any C2PA credentials.

The Breakthrough in Live Stream Provenance Validation

As for C2PA’s support for provenance validation in live video streams, the process incorporated in the recently issued Version 2.3 specifications is much simpler than preceding techniques used with stored files. But it requires compatible device player software, which is just emerging as early adopters like Bitmovin’ and Red5 incorporate C2PA plug-ins with their players.

The first demonstration of real-time C2PA provenance verification with live-streamed content occurred at the 2026 NAB Show in Las Vegas, where content protection provider EZDRM teamed with engineering, testing and consulting firm Qualabs to implement the solution the two helped C2PA develop for recently released Version 2.3 specifications. As described by Qualabs, cryptographically signed metadata formatted as a universally unique identifier (uuid) box is injected in-band into each multi-frame segment by a signing proxy during the packaging process.

Within 500ms of receiving a segment that’s missing the metadata, a client player equipped with a C2PA plug-in module known as a validator delivers an alert warning that the validation chain has been broken by interlopers.

Along with activating the live-stream C2PA demonstration using C2PA Rust SDKs (C2PA-RS) to work with CMAF in HLS and MPEG-DASH streams and tuning the C2PA JavaScript repository (C2PA-js) to ensure player-side verifications synchronize with playback, EZDRM and Qualabs collaborated with Ateme to bring the verification process into play with streaming formatted to the emerging MOQ standard. This entailed adapting processing in MOQ Relays to sign content in real time with the arrival of each stream segment.

As with the other streaming modes, EZDRM’s validator is integrated directly with the MOQ player to read the embedded metadata, replay the cryptographic hash chain, and verify signatures, thereby triggering tamper alerts without interrupting playback. All the capabilities demonstrated by EZDRM at NAB are embodied in the EZDRM Video Signature Service, the first Level 2 conformance generator to be verified by C2PA, which is offered as an option with EZDRM’s Universal Complete multi-DRM service.

The accomplishment bodes well for broader use of C2PA as other suppliers learn the ropes and adjust capabilities to those demonstrated by the EZDRM team, which is working on making the real-time live validation process available for use with VOD content. This would overcome the drawback in previous C2PA playback validations, which, according to documentation from AWS, can take anywhere from several seconds to minutes when C2PA labels are visible or hours to days when there’s no way to know whether C2PA is in use without searching for invisible forensic marks.

Vulnerabilities to Relying on C2PA

But vulnerabilities intrinsic to the design of C2PA as described in C2PA documentation and other reports, including a recent critique issued by a team of researchers from the University of Maryland, the National Security Agency and elsewhere. leave open the question of what more needs to be done to protect against AI deepfakes as malefactors get better at what they do. Some of the more likely points of attack against C2PA validation involve stripping unprotected metadata manifests and re-posting the content without provenance information or shifting the manifests to alternative content files while using purloined C2PA signing keys to assign the deepfakes the provenance.

Drilling down to specific instances, one new report names a remote code execution vulnerability tied to Adobe’s C2PA-based Content Authenticity Initiative. And there are other instances where attackers manage to compromise the C2PA validator or even the underlying validation logic. More fundamentally, C2PA doesn’t show whether content was manipulated before it was recorded, in which case a deepfake signed at the moment of creation is deemed authentic.

A number of entities have developed blockchain-based modes of media authentication that create immutable records of content provenance that aren’t subject to capture through distribution. If projects like Numbers Protocol and Starling Lab, which are described in this analysis, get significant traction they could be combined with C2PA standards to create a more trustworthy chain of provenance validation, but that’s a big “if,” which, in any case, would take quite a while to make a difference.

Uncertainties in the Detection Battle against Deepfakes

Meanwhile, there’s a rapidly expanding supply of solutions that take the alternative route to battling deepfakes through ever-more sophisticated modes of detection. But here, too, as some of the developers themselves acknowledge, there are no slam dunks in the fast-paced race between deepfake detectors and perpetrators seeking to seize the technology edge. And, as in the case of C2PA only more so, scale of adoption is a big issue as detection modes battle for market traction.

As described in this overview by the AI Security & Safety Directory, an anonymously maintained site hosting a voluminous repository of information about AI companies and organizations, detection solutions from the likes of Imagera, Usefulai and Resemble AI identify deepfakes by looking for clues often undetectable by human observation. They detect things like inconsistency in lighting and shadow, unnatural skin texture, irregular eye reflections, and spectral patterns that differ from camera-captured imagines.

The Hacker Pushback

But, so far, no matter how sophisticated the solutions might be, the generators of deepfakes have been able to adapt their models to overcome newfound vulnerabilities. As the security consulting firm Adaptive Security put it in a recent blog, “Every improvement in deepfake detection triggers a corresponding countermeasure in generation systems.”

Noting that deepfake generators’ AI systems training against detector feedback loops are able to identify and suppress “the very artifacts detectors are taught to identify,” Adaptive Security says, “The result is a permanent cat-and-mouse dynamic with no stable equilibrium. When detectors learn to flag unnatural blinking patterns, generators retrain with eye-movement regularization; and when detectors target heartbeat signals in facial blood flow, generators begin modeling physiological signals.”

Misleading Performance Metrics & Other Issues

It doesn’t help that providers of deepfake detection solutions appear to be putting out misleading performance metrics. A recent analysis conducted by the U.K.’s Department for Science, Innovation and Technology highlighted research showing that accuracy rates reported under lab conditions typically drop 10-20% when solutions were tested under real-world conditions where variables like demographic diversity and changing lighting conditions complicate detection processes.

Analysis by the cyber security company Brightside recently put an even harsher light on the lab-vs.-real-world-results disparity. “Commercial deepfake detection tools face a harsh truth when they leave the controlled environment of research labs and enter the messy reality of business operations,” Brightside said. “That impressive 96% accuracy? It drops to somewhere between 50% and 65% in actual use. Suddenly, you’re barely doing better than a coin flip.”

There are other issues confronting detection providers, such as the fact that a lot of the nuances they’re tuned to look for as proofs of legitimacy are stripped by encoders in compression processes that do away with content elements that are considered unimportant to delivering good viewing experiences. And, given all the ways deepfakes are used to distort reality, detection systems which typically aren’t designed to cover all those bases are bound to miss sometimes.

While some of the more sophisticated multi-mode detectors now entering the market aim to address this problem, it’s too soon to get a read on their impact.

Preparing for What Comes Next

Looking at the provenance validation and deepfake detection solutions at hand and the challenges attending widescale adoption, no one can say if and when the tide will be turned against the deepfake torrent. But it’s clear that streamed content providers should do everything they can to improve their chances of success by choosing streaming transport architectures and media layer platforms that can facilitate execution of deepfake deterrence.

The motivation in this direction is sure to intensify as regulatory bodies come to grips with the deepfake challenge, as has already happened with the EU AI Act and China’s new AI labeling rules and is queued up with bipartisan backing of proposed but stalled U.S. legislation.

However the rulemaking goes, it’s likely the global battle against deepfakes will take a multi-pronged approach in the immediate future by tapping into various mixes of provenance validation and detection platforms. It’s even possible a scenario suggested by Adaptive Security eventually prevails where provenance identification is so pervasive “we may move to a model where media is untrusted by default and authentication is required to establish trust.” the previously quoted Secure Analytics blog suggests.

But we’re a long way from getting there. “This paradigm shift would fundamentally change how media is consumed, shared, and used in decision-making,” the blog writer adds, noting this “would require widespread adoption of content authentication standards that are still in early stages.”

Consequently, for now, when it comes to choosing streaming platforms with deepfake mitigation in mind, the best recourse is to go with those that are optimized to cover all bases. This is where what Red5 has to offer comes into play.

Leveraging XDN Edge Intelligence

One aspect to our support for deepfake deterrence that’s enabled by our Experience Delivery Network (XDN) Architecture centers on the ways in which deep-edge positioning of intelligent XDN nodes expedites processing for both C2PA provenance and fake detection applications.

Intelligence orchestrated by the XDN Stream Manager enables output, no matter how many streams may be coming in from upstream Origin and Relay Nodes, to be tuned to requirements associated with each use case, whether the goal is delivery of a live stream to end users or transmission of a video segment for parsing in deepfake deterrence.

This XDN edge intelligence supports Red5’s approaches to ABR profile streaming, dynamic ad and other content insertions, watermark extractions, multiviewing and much else. In all cases we have engineered our XDN software to enable egress latency that doesn’t exceed 10ms with video delivery from deep edge locations to end points occurring at sub-50ms latencies.

At the same time, Origin Nodes can be co-located with Edge Nodes to accommodate ingestion of massive volumes of streams at minimum latency in interactive scenarios serving all end points. Whatever the use case might be, it doesn’t matter whether just a few, thousands or even millions of users are engaged or where they are.

Support for Real-Time C2PA Validation

In the case of Red5’s support for C2PA validation, the emergence of the previously discussed player-centered real-time C2PA solution is a big help. Here it’s important to note that we are partnering with EZDRM to bring these capabilities into play wherever XDN Architecture is deployed.

Look for more information soon about how this can be done with MOQ, WebRTC and conventional HTTP streaming on the managed Red5 Cloud service or with Red5 Pro DIY implementations of XDN infrastructures. At the same time, in instances where that solution isn’t supported, especially in the case of stored content viewing, Edge Node support for minimizing roundtrip latencies associated with cloud-based C2PA validation of content segments remains essential.

Making Deepfake Detection Effective in Live Streaming

As for deterrence involving deepfake detection, extraction of video for analysis is another application that calls for minimal latencies. While there are solutions designed to leverage device computing power in the detection process, the computing power required to execute the best approaches requires use of cloud resources. Or, as the Alliance for Forensic Integrity & Provenance puts it, “Multi-model ensemble approaches that achieve the highest accuracy in research settings are often too computationally expensive for real-time deployment.”

Latency imposed by common approaches to video frame extraction can be a major impediment to cloud-based deepfake detections involving live streams. As explained by Adaptive Security, “For viable live-call detection, such as flagging a deepfake participant in a Zoom or Teams meeting, the total detection pipeline must complete within roughly 300 milliseconds end-to-end. Beyond this threshold, the alert arrives after the conversation has moved on, rendering it operationally useless.”

One aspect to meeting this challenge is the ultra-low latency achieved with XDN Edge Node to cloud transmissions. At the same time, as we report in this blog, the Red5 video frame extraction service overcomes the latency barrier imposed by even the fastest frame extraction techniques, which typically take a few seconds and even at the lowest 500ms-1-second levels are impediments to effective deepfake detection with live streaming. In contrast, Red5’s extraction service can be used to extract frames for deepfake detection in milliseconds from any live stream, including high-latency HTTP-based streams as well as from MOQ and WebRTC streams delivered at real-time speeds over XDN infrastructures.

When HTTP Live Streaming (HLS), MPEG-Dynamic Adaptive Streaming over HTTP (DASH) or another conventional streaming mode is involved, the post-production playout stream is delivered as usual over CDNs to end users while, at the same time, the feed is ingested by the XDN Architecture for real-time frame extraction at whatever intervals users set on their Red5 extraction dashboards. In this approach, there’s no end-to-end distribution involving egress from a cloud XDN infrastructure to end users.

Instead, as dictated by the user, the extracted frames are pushed into S3 or another cloud-based object storage platform, where the user’s chosen mode of deepfake detection can be applied instantly to execute the relevant tasks. Depending on the speed of the detection process, those tasks can often be completed before the HTTP-streamed primary content reaches end users, especially in cases where the streaming entity employs low-latency backend connections to the storage repositories.

Alternatively, in instances where streamers have activated real-time streaming end to end over Red5 Cloud XDN infrastructures, there’s no need to push the extracted frames into storage. Instead, distributors can instantly apply any detection solution that’s been integrated with the Red5 Cloud service to execute the process within the real-time streaming parameters, typically at 250ms or lower end to end, that are supported by XDN Architecture.

Expediting Integration of Deepfake Detection Tools

Adding to the advantages Red5 brings to deepfake detection, our open-source API approach to integrating AI solutions into customers’ streaming applications facilitates their ability to leverage new detection solutions as they come to market. Such integrations build on the large ecosystem of AI Large Language and Vision Language Models (LLMs and VLMs) that are already available to Red5 customers, as described in this blog.

Conclusion

The global battle against AI deepfakes is taking on ever greater urgency as the business and cultural toll exacted by deception intensifies. But anyone looking to deter the aggressors must deal with the fact that nothing yet has taken hold as an undefeatable deterrent.

That suggests the best course of action is to be positioned to take advantage of the best solutions at hand with the flexibility to adapt as better ones emerge. Contact us to learn more about how Red5 customers can be assured they are operating in a streaming environment that will maximize their deterrence impact at each stage of the anti-fake evolution ahead.