DEV Community: Maria Artamonova

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.

MOQ Mobile: Building Real-Time iOS and Android Apps

Maria Artamonova — Fri, 18 Sep 2026 05:00:14 +0000

MOQ mobile app development could make phones first-class endpoints for real-time media, not just screens for watching a stream. Native iOS and Android applications could publish camera, microphone, screen, and application data to a relay while also subscribing to live video, audio, and related data.

That does not make MOQ a production-ready replacement for every mobile WebRTC workflow. WebRTC has mature SDKs, broad device support, and a proven role in calls and interactive sessions. MOQ is earlier, but its relay-oriented publish-and-subscribe model creates an interesting foundation for one-to-many and large-scale interactive applications.

This article builds on a recent LinkedIn post of mine that generated significant engagement among streaming and mobile professionals, particularly around ICE complexity, native SDKs, mobile reliability, and QUIC performance during network congestion.

Why MOQ Mobile Matters

When people discuss MOQ (Media over QUIC), the conversation often centers on relays, content delivery networks, or browser clients. Those areas matter, but native mobile applications may become one of MOQ’s largest practical categories because phones are already central to live commerce, creator platforms, sports, remote monitoring, public safety, and field operations.

A phone is both a media source and a media destination. It has cameras, microphones, hardware codecs, a display, sensors, local storage, and a network connection that can move between Wi-Fi and cellular service. A useful mobile streaming SDK therefore needs to do more than play video. It should give developers a coherent way to capture, publish, discover, subscribe to, render, and control real-time media.

MOQ Transport organizes media and other application data as addressable objects within tracks and groups. A mobile client can publish or subscribe through a relay, while the relay handles fan-out and can participate in a wider delivery network. The current IETF MoQ Transport draft is still evolving, so implementers need to track versions and test interoperability rather than assume that every draft or library works with every other one.

The Emerging MOQ Mobile SDK Ecosystem

Native app support depends on libraries that expose protocol capabilities through APIs mobile developers can actually use. As I discussed in my article about MOQ hardware support, the protocol will not succeed through specifications alone. It needs practical implementations across clients, relays, encoders, players, and devices.

One foundation is MOQ5, an open-source native C library developed by the Red5 team and published through OpenMOQ. It provides a transport-independent protocol core plus higher-level services for sending and receiving media. The MOQ5 repository currently describes the project as pre-1.0 and explicitly tells developers to verify it against their own endpoints before depending on it in production.

MOQ5 has Swift integration work for Apple platforms, and Kotlin support is part of the Android direction. My team at Red5 is building iOS and Android SDKs on top of MOQ5. The goal is not playback alone. We want native applications to publish and subscribe through MOQ, which would allow the same phone to capture a live event, receive other tracks, and exchange related application data.

OpenMOQ member Bitmovin is also working to incorporate MOQ5 into its mobile player efforts for iOS and Android. This is ecosystem development rather than a statement that generally available MOQ playback has already shipped in every Bitmovin mobile product.

There are separate mobile efforts outside MOQ5 as well. Software Mansion’s MoQKit provides preview Swift and Kotlin APIs for publishing and playing low-latency streams on iOS and Android. It is built on Luke Curley’s Rust-based moq-lite implementation, not on MOQ5, and its public repository warns that APIs and relay compatibility may still change. That distinction matters when comparing demos or planning interoperability tests.

How MOQ Mobile Differs From WebRTC

The question is not whether MOQ is newer than WebRTC. The useful question is whether its connection and distribution model solves a specific application problem with less operational friction.

A Simpler Server Connection, Not a Zero-Complexity System

WebRTC uses Interactive Connectivity Establishment (ICE) to discover and test network paths, with STUN and TURN supporting NAT and firewall traversal. This is proven technology, but it introduces signaling, candidate gathering, connectivity checks, relay credentials, and failure cases that developers must understand. The IETF’s WebRTC IP address handling requirements also explain why candidate discovery creates privacy considerations that implementations need to manage.

A native MOQ client typically connects to a known relay over QUIC and does not use ICE to establish that client-to-server session. That can simplify one part of the connection process, but it does not remove TLS, authentication, authorization, relay discovery, congestion control, recovery, or network policy. It is a different operational model, not an automatic shortcut around every networking problem.

Relay Interoperability and Multi-CDN Potential

Scaled WebRTC platforms can use different APIs, authentication models, tokens, routing logic, and media-server behavior. WHIP and WHEP standardize important ingest and egress workflows, but they do not standardize an entire multi-CDN control plane.

MOQ is designed so compatible publishers, subscribers, and relays can exchange the same protocol objects. That creates a path toward relay-to-relay distribution and vendor choice closer to what media companies expect from HLS and DASH delivery. It does not guarantee instant portability. Draft versions, namespaces, catalogs, authorization, caching policy, and operational interfaces still need to align across providers.

Where Mobile MOQ Could Create Value

Live commerce: A host could publish camera and microphone tracks from a phone while shoppers subscribe to the live presentation and receive synchronized product or inventory data.
Creator platforms: The same application could support going live, watching other creators, switching renditions, and exchanging chat or control data without treating publishing as a separate product.
Sports experiences: Fans could watch a low-latency main feed, select alternative camera tracks, receive statistics, and move between live action and recent objects retained by the delivery system.
Public safety and field operations: Personnel could publish live video from the field while subscribing to command-center video, maps, telemetry, or instructions through the same application.
Remote monitoring: Mobile technicians could view low-latency camera feeds, publish their own video for assistance, and exchange application data with operators or automated systems.

These scenarios do not require every media flow to be perfectly symmetrical. A creator may publish one high-value camera track and subscribe to several lower-bitrate return feeds. A viewer may only subscribe to video but publish reactions or control data. A field operator may switch roles during a session. The value is having a model that supports both directions without defining mobile as a playback-only endpoint.

MOQ Mobile App Development Checklist

Choose the implementation and protocol version. Identify the library, relay, MoQ Transport or moq-lite draft, and media format you will test. Pin compatible versions because the ecosystem is still changing.
Define publish and subscribe roles. Document which camera, microphone, screen, video, audio, and data tracks each user role can send or receive.
Design the native media pipeline. Plan capture, hardware encoding and decoding, track selection, rendering, audio-session behavior, permissions, and interruption handling for both iOS and Android.
Plan authentication and authorization. Define how the app obtains credentials, how relay namespaces map to users or events, and which roles can publish, discover, or subscribe to each track.
Build network fallbacks. Test cellular, Wi-Fi, VPNs, captive portals, and corporate networks. If UDP or QUIC is blocked, the application needs a documented fallback or a clear failure path. Red5’s current MOQ implementation, for example, documents a WebSocket tunnel fallback.
Measure quality on real devices. Track startup time, glass-to-glass latency, bitrate adaptation, frame drops, reconnect time, battery use, thermal behavior, CPU and memory use, and performance during Wi-Fi-to-cellular transitions.
Test interoperability separately from functionality. A working publisher and player from one project do not prove compatibility with another relay or draft. Build an explicit matrix of client, relay, draft, media format, codec, and authentication combinations.

What the Ecosystem Still Needs to Solve

The first challenge is stability. MoQ Transport remains an Internet-Draft, implementation support varies by draft, and related media-format work continues. Mobile SDKs need stable application-facing APIs even when protocol details change underneath them. Developers also need clear compatibility documentation rather than a generic statement that a client or relay “supports MOQ.”

The second challenge is mobile network behavior. QUIC normally uses UDP, but enterprise firewalls, VPNs, and carrier networks do not all treat UDP traffic the same way. Connection migration may help when a device changes network paths, yet applications still need to test what happens during real handoffs, packet loss, radio changes, and background execution.

The third challenge is product completeness. A protocol library does not automatically provide camera capture, hardware codec integration, adaptive bitrate logic, playback controls, digital rights management, advertising, analytics, accessibility, offline behavior, or polished recovery states. Strong native SDKs must connect the protocol to the platform features developers expect.

Privacy also needs careful language. Avoiding ICE may reduce the address-discovery surface associated with ICE candidate exchange in some client-to-server designs. It does not make a mobile application anonymous, hide its public address from the relay, or eliminate the need for secure identity, authorization, logging, and data-handling policies.

FAQs

What does MOQ mobile mean?

MOQ mobile refers to using MOQ (Media over QUIC) in native iOS or Android applications. A mobile client can connect to a compatible relay to publish or subscribe to real-time media and related application data. The ecosystem is emerging, so library, draft, relay, codec, and media-format compatibility still require testing.

Can MOQ replace WebRTC in mobile apps?

MOQ may become a useful alternative for relay-based, one-to-many, and interactive broadcast applications, but it is not a universal WebRTC replacement. WebRTC remains more mature for peer-to-peer calls, conferencing, and established real-time products. Choose between them based on topology, scale, interoperability, latency, device support, and operational requirements.

Does MOQ work on iOS and Android?

Early native implementations are available for both platforms. MOQ5 has Swift integration work and an Android SDK direction, while Software Mansion’s separate MoQKit preview offers Swift and Kotlin APIs. These projects do not share the same implementation or necessarily the same protocol profile, so developers must verify current versions and relay compatibility.

Can a mobile MOQ app publish as well as play video?

Yes, an appropriate mobile SDK can expose both publishing and subscribing. A phone could publish camera, microphone, screen, or data tracks while receiving video, audio, and application data through a relay. Exact capabilities depend on the selected SDK, operating-system permissions, codecs, media format, relay, and protocol version.

Conclusion

MOQ mobile development deserves its own place in the protocol conversation because phones can publish, subscribe, render, capture, and exchange application data. That combination could support live commerce, creators, sports, monitoring, public safety, and other real-time experiences without treating mobile as an afterthought.

I do not think every question has been answered. Developers still need stable SDKs, version interoperability, network fallbacks, strong security, and extensive device testing. What is clear is that MOQ will succeed only if developers have useful native tools and can turn them into reliable applications. That is where the next stage of this ecosystem gets interesting.

Bandwidth vs Latency: What Matters for Live Streaming?

Maria Artamonova — Thu, 17 Sep 2026 05:00:14 +0000

Bandwidth vs latency is the difference between how much data a network can carry and how long that data takes to arrive. A connection can have enormous capacity and still feel slow in an interactive stream. It can also respond quickly while lacking enough capacity to sustain high-quality video.

For live video teams, the practical lesson is simple: path capacity sets the upper limit, while sustained available throughput or goodput determines whether the media bitrate can be delivered reliably. Latency determines how quickly viewers see and respond to the event. Jitter, packet loss, encoding, buffering, and protocol behavior also shape what users actually experience.

This guide explains each metric, shows how they interact, and provides a measurement and troubleshooting process for real-time and one-to-many streaming systems.

Bandwidth vs Latency at a Glance

Metric	What it measures	Typical unit	Streaming symptom when poor
Bandwidth	The maximum data rate a link or path can carry under defined conditions	Mbps or Gbps	Quality reductions, buffering, or failed publishing
Latency	The time data needs to travel from one point to another	Milliseconds	Delayed reactions, talk-over, late bets, or stale video
Throughput	The rate at which data is transferred over a link or flow	Mbps or Gbps	Observed transfer rate falls below the required level
Goodput	The useful application-data rate after retransmissions, duplicates, and other non-contributing traffic are excluded	Mbps or Gbps	Media delivery falls below the required bitrate
Jitter	Variation in packet delay	Milliseconds	Uneven playback, buffer growth, audio gaps, or frame drops
Packet loss	The share of packets that never arrive	Percentage	Artifacts, freezes, retransmissions, or quality adaptation

Bandwidth is capacity, not a promise of delivered performance. Latency is delay, not a measure of how many bits can move at once. Throughput is the observed transfer rate. Goodput is the useful application-data rate after retransmissions, duplicates, and other non-contributing traffic are excluded.

Fastest way to remember it: bandwidth describes the width of the pipe. Latency describes the travel time through the pipe. Throughput describes the observed flow, while goodput describes the part that delivers useful application data.

What Is Bandwidth?

In this article, bandwidth is used informally to describe path capacity: the maximum data rate a path can carry under defined conditions. Available path capacity is the portion currently available to a flow after competing traffic and other constraints. A stream is sustainable only when measured application delivery rate remains above its media bitrate, protocol overhead, and operating headroom.

A 100 Mbps uplink does not guarantee that an encoder can continuously send 100 Mbps to a remote media server. Other applications may share the link. Wi-Fi contention, protocol overhead, peering, congestion, packet loss, and the slowest segment of the route can all reduce available path capacity and measured application goodput.

Bandwidth in a Streaming Workflow

For contribution, the publisher needs stable upload goodput above the encoded audio and video bitrate. For delivery, each viewer needs enough sustained goodput for the selected rendition. The platform also needs aggregate capacity between origin, relay, edge, and egress layers.

A single 5 Mbps stream is modest for a modern network. Ten thousand viewers receiving that same rendition represent roughly 50 Gbps of media payload before transport overhead and operational headroom. That is why per-user bandwidth and platform-scale capacity must be planned separately.

What Is Latency?

Latency is elapsed time. A network test may measure one-way delay or round-trip time (RTT), while a streaming team often cares about glass-to-glass latency from camera capture to playback. These values are related, but they are not interchangeable.

The IETF defines a formal one-way delay metric for internet paths. In production streaming, total delay also includes capture, encoding, packetization, server processing, transcoding, routing, player buffering, decoding, and rendering.

The Four Network Delay Components

Propagation delay: the time a signal needs to cross the physical distance between endpoints.
Transmission delay: the time required to place all packet bits onto the link.
Queuing delay: time packets wait behind other traffic in routers, switches, or access equipment.
Processing delay: time network devices spend inspecting, routing, encrypting, or otherwise handling packets.

Distance creates a physical floor. More bandwidth cannot make light travel faster. Better routing and edge placement can shorten the path, while congestion control and traffic engineering can reduce avoidable queuing.

Where Throughput, Jitter, and Packet Loss Fit

Throughput is the rate at which data is transferred over a link or flow. Goodput is the portion consisting of useful application data, excluding retransmissions, duplicates, and other traffic that does not contribute to completed media delivery. For video planning, sustained application goodput matters more than an advertised link rate or a brief speed-test peak.

Jitter describes variation in packet delay. A stream can tolerate a stable 80 ms path more predictably than a path jumping between 30 and 250 ms. A receiver may add a jitter buffer to smooth arrivals, but that resiliency adds playback delay.

Packet loss reduces quality or triggers recovery. Real-time media may conceal or skip late packets to preserve immediacy. Reliable transports may retransmit them, which protects completeness but can increase delay. The right behavior depends on whether the application values timeliness, fidelity, or recoverability most.

How Bandwidth and Latency Interact

Bandwidth and latency are independent measurements, but congestion can connect them. When offered traffic approaches or exceeds available capacity, packets queue. Throughput may flatten while delay rises sharply. If buffers keep growing, users experience lag before they see outright packet loss.

When More Bandwidth Helps

More capacity helps when the bottleneck is saturation. It can remove queues caused by competing uploads, multiple high-bitrate feeds, or a busy office connection. It also provides room for bitrate spikes and retransmissions. In that situation, an upgrade may improve both sustainable throughput and observed latency under load.

When More Bandwidth Does Not Help

An upgrade will not solve delay dominated by geography, inefficient routing, long media segments, oversized playback buffers, slow encoding, or overloaded application servers. A 10 Gbps path can still have a 150 ms RTT. Capacity has increased, but the time for each packet to make the round trip has not.

Why the Bandwidth-Delay Product Matters

The bandwidth-delay product estimates how much data can be in transit before an acknowledgment returns. It is especially relevant to reliable, window-based transport on long-distance, high-capacity paths.

Bandwidth-delay product = bandwidth × round-trip time

25 Mbps × 0.10 seconds = 2.5 megabits, or about 312.5 KB, in flight

If transport windows or buffers are too small for that path, the sender may fail to use the available capacity. This is one reason a high-bandwidth, high-latency connection can underperform expectations.

How Each Metric Affects Live Video Streaming

One-Way Broadcast Viewing

For a passive broadcast, enough available path capacity and stable goodput usually matter more than conversational immediacy. A player can buffer several seconds to absorb variation. Viewers may accept a delay if playback remains smooth, especially for scheduled programming without synchronized interaction.

Interactive and Two-Way Video

Auctions, sports betting, remote control, conferencing, and live shopping cannot hide delay behind a large buffer. These applications need adequate capacity plus consistently low end-to-end latency. A high-resolution picture that arrives too late can be less useful than a lower-resolution rendition that remains current.

Adaptive Quality Under Changing Conditions

Adaptive bitrate streaming gives the player or server multiple renditions to choose from. When available throughput falls, the system can switch to a lower bitrate instead of allowing queues, loss, and rebuffering to grow. The goal is not always the highest resolution. It is the best sustainable quality within the current network budget.

Red5 Pro supports server-side transcoding and adaptive-bitrate subscribing in documented, appropriately configured deployments. Current requirements include Red5 Pro Autoscaling, the Stream Manager API, and an eligible server license; supported minimum versions vary by server and client SDK. Its resolution and bitrate guide provides practical starting points, but production ladders should still be validated against content, devices, and real audience networks.

How Protocol Choice Changes the Tradeoff

Protocols cannot remove the laws of physics, but they make different choices about buffering, recovery, congestion control, browser support, and scale.

WebRTC for Real-Time Interaction

WebRTC is designed for real-time audio, video, and data. It adapts sending behavior to changing conditions and exposes useful browser telemetry. The W3C WebRTC statistics specification includes current round-trip time, available outgoing bitrate, jitter, and packet-loss metrics, which can support session-level diagnosis.

HLS for Reach and Buffering Resilience

HLS uses HTTP delivery, segmented media, and playback buffers to provide broad compatibility and scalable distribution. Those buffers improve resilience but add delay. Low-Latency HLS reduces traditional HLS delay through partial segments and related delivery extensions. Actual glass-to-glass latency depends on segment and part duration, origin and CDN behavior, player configuration, and network conditions. Compare LL-HLS and WebRTC using the same workflow and the application’s measured latency target.

MOQ (Media over QUIC) for Emerging Workflows

MOQ (Media over QUIC) is an emerging publish-subscribe approach built on QUIC. As of July 6, 2026, MOQT is an active IETF Internet-Draft, draft-ietf-moq-transport-19. It defines a media-agnostic publish-subscribe protocol over QUIC or WebTransport and remains work in progress. Teams should evaluate current implementation and client support before choosing it for production.

How Much Bandwidth Does a Live Stream Need?

Start with encoded video bitrate, audio bitrate, protocol overhead, concurrent streams, and headroom. Do not size a workflow from resolution alone. Motion, frame rate, codec, encoder settings, audio configuration, and quality targets all change the required bitrate.

Publisher Upload Calculation

For one 4.5 Mbps video track and 128 Kbps audio track, the encoded payload is about 4.63 Mbps. Add transport overhead and operational headroom rather than configuring the stream at the absolute speed-test result. If the venue shares its uplink, reserve capacity for other traffic or isolate the contribution network.

Viewer and Platform Calculation

For direct delivery, multiply the selected rendition bitrate by concurrent viewers, then add overhead and headroom. With adaptive delivery, model the expected distribution across renditions rather than assuming every viewer receives the top profile. Also calculate inter-node traffic and multi-region replication separately from viewer egress.

Planning rule: use measured sustained application goodput, not the ISP’s advertised link rate, and keep a margin for variation. The appropriate margin depends on network ownership, Wi-Fi use, mobility, congestion, and how aggressively the application can adapt.

How to Measure Bandwidth and Latency Correctly

Measure Capacity and Sustained Throughput

Run upload and download tests from the actual publishing and playback networks, at representative times, and to relevant regions. Record sustained results, not only peaks. Test wired and wireless paths separately. A local speed-test server may show access-link capacity while hiding a weak route to the streaming infrastructure.

Measure Network Delay and Stability

Measure RTT with repeated probes and review median, high-percentile, and worst-case results. Track jitter and loss at the same time. For one-way delay, use synchronized clocks and a suitable measurement method. A single ping does not describe a session, and ICMP handling may differ from media traffic.

Measure Glass-to-Glass Streaming Latency

Place a visible clock or timecode in the captured scene and compare it with the rendered output using synchronized reference timing. Repeat across devices, networks, and regions. This captures the entire media chain, which a network RTT test cannot do.

Measure the Application, Not Just the Link

Correlate network metrics with encoder output, frame rate, keyframe interval, server processing, selected rendition, player buffer, dropped frames, rebuffering, and time to first frame. Observability should follow a stream from publisher to viewer so teams can identify where delay or capacity loss begins.

How to Troubleshoot a Streaming Problem

Symptom: Buffering or Frequent Quality Drops

Compare media bitrate with sustained application goodput, then inspect loss, jitter, and competing traffic. If the path is saturated, lower the rendition, improve adaptive logic, move publishing to wired Ethernet, apply traffic prioritization, or increase capacity at the actual bottleneck.

Symptom: Smooth Video That Arrives Too Late

Inspect glass-to-glass stages. A large player buffer, long HLS segments, distant media nodes, slow transcoding, or a reliability setting that waits for recovery can add delay even when throughput is excellent. Reduce the dominant stage instead of purchasing capacity blindly.

Symptom: Performance Degrades Only Under Load

Test for queueing delay by comparing idle latency with latency during upload and download. Review interface utilization and server resource saturation. If latency rises with load, capacity, queue management, autoscaling, or traffic isolation may be the real fix.

Symptom: Only Distant Viewers Struggle

Compare routes and application metrics by region. Geography, transit, peering, and edge placement may dominate. A distributed architecture can shorten the media path and reduce the number of unpredictable networks between users and the streaming service.

How to Improve Streaming Performance

Match bitrate to sustained goodput. Build a ladder that covers real audience conditions rather than ideal laboratory links.
Keep media close to users. Use regional ingest, relays, and edge delivery to shorten long paths.
Choose the protocol for the experience. Interactive applications need different buffering and recovery behavior from passive viewing.
Control queues. Add capacity where utilization is high, prioritize real-time traffic, and avoid oversized unmanaged buffers.
Use wired publishing links when possible. Ethernet removes much of the contention and interference common on Wi-Fi.
Tune encoding and playback. Review keyframe intervals, encoder latency modes, segment duration, jitter buffers, and player buffers as one system.
Monitor percentiles and trends. Averages can hide short periods of delay, loss, and bitrate collapse that disrupt live sessions.

A Network Design Checklist for Live Video

Define acceptable end-to-end latency for each user action, not just for video playback.
Document contribution bitrate, rendition ladder, audio bitrate, overhead, and concurrency assumptions.
Measure upload and download throughput and application goodput from representative networks and regions.
Measure idle and loaded RTT, jitter, loss, and glass-to-glass delay.
Choose protocol, recovery, and buffer settings that match the application’s tolerance for delay and artifacts.
Place media processing and delivery nodes close to publishers and viewers.
Expose session telemetry so support teams can separate client, access-network, route, server, and player problems.
Load-test the complete workflow, including transcoding, relays, signaling, and egress.
Retest after routing, encoder, player, or infrastructure changes.

FAQs

Is bandwidth the same as latency?

No. Bandwidth is the capacity of a link or path, usually measured in Mbps or Gbps. Latency is the time data takes to travel, usually measured in milliseconds. A connection can have high bandwidth and high latency, or low bandwidth and low latency, because the metrics describe different properties.

Does higher bandwidth reduce latency?

Only when congestion is causing packets to queue. Adding capacity can shorten those queues and improve loaded latency. It will not remove delay caused by distance, routing, encoding, server processing, media segmentation, or player buffers. Measure the delay source before upgrading the link.

Which is more important for streaming, bandwidth or latency?

Both matter, but priority depends on the experience. One-way viewing needs enough sustained application goodput for stable quality and can tolerate buffering. Conferencing, auctions, betting, remote control, and live shopping also need consistently low end-to-end latency so actions and video remain synchronized.

How do you test bandwidth and latency?

Test sustained upload and download throughput to relevant regions, then measure repeated round-trip times, jitter, and packet loss under idle and loaded conditions. For streaming, add a glass-to-glass test and inspect encoder, server, transport, and player telemetry. One speed-test result is not enough.

What is good latency for live streaming?

Interactive streaming commonly targets less than one second, but conversational and control-feedback applications may require substantially lower glass-to-glass latency. Define the target from interaction, safety, and fairness requirements, then validate it under representative devices, routes, and load before deployment at scale.

Build Live Video for Real Network Conditions

Red5 Pro and Red5 Cloud support real-time and adaptive streaming workflows that can be deployed across cloud, on-premises, and edge environments. Teams can combine protocol choice, transcoding, autoscaling, and distributed delivery to meet both capacity and delay requirements.

Test Your Streaming Architecture

See how Red5 can help you deliver live video with the throughput, adaptability, and end-to-end latency your application requires.

GET IN TOUCH >

Conclusion

Bandwidth answers “how much,” while latency answers “how long.” A reliable live video experience needs enough sustained application goodput for the chosen bitrate and a delay budget that fits the interaction. Measure both under real load, include jitter and loss, and trace the entire media pipeline before deciding whether to add capacity, shorten the path, change the protocol, or tune the application.

Vue Streaming Tutorial: Build a Live Video Streaming App With WebRTC (WHEP)

Maria Artamonova — Wed, 16 Sep 2026 05:00:12 +0000

Vue streaming can be added to a Vue 3 application without building a video player from scratch. In this tutorial, you will create a reusable WHEP player that accepts a Red5 Cloud host, stream name, and node group; subscribes to a live stream; and retries the connection if playback ends unexpectedly. The implementation is based on Red5’s Vue 3 + TypeScript + Vite example repository.

This specific example uses Red5 Cloud. The Red5 HTML SDK can work with Red5 Pro or Red5 Cloud, but this repository’s default red5.net host, node-group parameter, and proxy WHEP endpoint are configured for Red5 Cloud. You still need a streaming deployment because the SDK supplies the browser client, not the media server.

What You Will Build

By the end, your Vue streaming page will let a user enter connection details, start and stop playback, view connection status, and recover from a closed connection after a short delay. The player uses WHEP, a WebRTC-HTTP egress protocol designed for receiving a live WebRTC stream in a compatible client.

A Vue 3 component that owns the WHEP subscriber lifecycle.
A native video element for browser playback.
Configurable host, stream name, and node group fields.
Status and error events that the parent component can display.
Optional retry behavior when a live stream is interrupted.

Why Use WHEP for Vue Streaming?

Vue is responsible for the application interface and component lifecycle. WHEP is responsible for how the browser receives the WebRTC stream. Combining them keeps the player logic inside a Vue component while the Red5 HTML SDK handles session setup, events, and media playback.

For protocol background, see Red5’s guide to WHIP and WHEP and its educational overview of WebRTC. The IETF’s WHEP specification draft describes the HTTP-based session model behind the protocol.

Vue Streaming Prerequisites

Node.js and a Vue 3 project created with Vite. Vue’s Quick Start guide explains the current project setup.
A Red5 Cloud deployment with a live stream to play.
The Red5 Cloud host name, stream name, and node group for that deployment.
A browser that can play WebRTC media and permission to access the relevant deployment.

Log in to your Red5 account to create or access a Red5 Cloud deployment. If you do not have an account, sign up for a free Red5 Cloud account – no credit card required.

Install the Red5 HTML SDK

Start with a Vue 3 + TypeScript + Vite project, then install the SDK package used by the repository. The Vite alias resolves the package to its ESM build, so the Vue component can import the WHEP client directly.

npm install red5pro-webrtc-sdk

// vite.config.ts
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

export default defineConfig({
plugins: [vue()],
resolve: {
alias: {
'red5pro-webrtc-sdk': 'red5pro-webrtc-sdk/red5pro-sdk.esm.min.js',
},
},
})

Keep the alias in vite.config.ts. It matches the repository and ensures the imported client is available to the browser build.

Create a Reusable Vue Video Player

Create src/components/VideoPlayer.vue. The component receives connection properties from its parent, builds the WHEP endpoint, initializes WHEPClient, and attaches playback to a native video element. Its watcher starts or stops the subscriber when the parent changes subscribed.

import { ref, watch, onUnmounted } from 'vue' import { WHEPClient, setLogLevel } from 'red5pro-webrtc-sdk' import type { RTCWhepSubscriberConfigType } from 'red5pro-webrtc-sdk' setLogLevel('warn') const props = defineProps<{ host: string streamName: string nodeGroup: string subscribed: boolean retryEnabled?: boolean retryDelay?: number }>() const emit = defineEmits<{ (e: 'error', message: string): void (e: 'status', payload: { msg: string; retry: boolean }): void }>() const VIDEO_ELEMENT_ID = 'red5pro-subscriber' const RETRY_DELAY_MS = 2000 const client = ref<WHEPClient | null>(null) const retryTimer = ref<ReturnType<typeof setTimeout> | null>(null) const isStarting = ref(false) async function clearClient() { if (client.value) { await client.value.unsubscribe() client.value = null } } async function startSubscription() { if (isStarting.value) return isStarting.value = true try { emit('status', { msg: 'Connecting...', retry: true }) const endpoint = `https://${props.host}/as/v1/proxy/whep/live/${props.streamName}` const config: RTCWhepSubscriberConfigType = { host: props.host, streamName: props.streamName, endpoint, mediaElementId: VIDEO_ELEMENT_ID, connectionParams: { nodeGroup: props.nodeGroup }, } const subscriber = new WHEPClient() subscriber.on('*', ({ type }: { type: string }) => { if (type === 'Subscribe.Start') { emit('status', { msg: 'Live', retry: true }) emit('error', '') } }) await subscriber.init(config) await subscriber.subscribe() client.value = subscriber } catch (err) { emit('error', err instanceof Error ? err.message : String(err)) } finally { isStarting.value = false } } watch(() => props.subscribed, active => { if (active) startSubscription() else clearClient() }) onUnmounted(() => clearClient())

The repository also handles closed connections and publish-end events by clearing the client and retrying after two seconds when retry is enabled. Add that event logic when your Vue streaming experience should recover automatically from temporary interruptions.

Add Stream Configuration and Controls

The parent component keeps the editable fields and UI state separate from the player. This makes it possible to disable configuration while the application is subscribed, show a useful status label, and pass the same values into the child component as typed props.

import { ref, computed } from 'vue'
import VideoPlayer from './components/VideoPlayer.vue'

const params = new URLSearchParams(window.location.search)
const host = ref(params.get('host') ?? 'your-deployment.red5.net')
const streamName = ref(params.get('streamName') ?? 'stream1')
const nodeGroup = ref(params.get('nodeGroup') ?? 'your-node-group')
const subscribed = ref(false)
const statusMessage = ref('Idle')
const errorMessage = ref('')

const canSubscribe = computed(() =>
host.value.trim() !== '' &&
streamName.value.trim() !== '' &&
nodeGroup.value.trim() !== '',
)

function toggleSubscription() {
errorMessage.value = ''
subscribed.value = !subscribed.value
if (subscribed.value) statusMessage.value = 'Connecting...'
}

function handleStatus({ msg, retry }: { msg: string; retry: boolean }) {
statusMessage.value = msg
if (!retry) subscribed.value = false
}

{{ subscribed ? 'Unsubscribe' : 'Subscribe' }}

:host="host"
:stream-name="streamName"
:node-group="nodeGroup"
:subscribed="subscribed"
:retry-enabled="true"
@status="handleStatus"
@error="message => (errorMessage = message)"
/>

For a production app, do not expose credentials in the Vue bundle. The values in this example identify a playback destination, but authentication, authorization, and token handling should follow your deployment’s security design.

Test the Vue Streaming App

Start a live stream on your Red5 Cloud deployment.
Run the Vue project with npm run dev.
Enter the host, stream name, and node group from the deployment, or pass them as URL query parameters.
Select Subscribe and confirm that the status changes from Connecting… to Live.
Stop the source stream and confirm that the player reports the expected state. If retry is enabled, restart the source and verify that the player reconnects.

If playback does not start, first verify that the stream is active and that the host, stream name, and node group match the deployment. Then inspect the browser console for the SDK error emitted by the component. The repository’s full source code includes the complete status and retry handling.

Vue Streaming Next Steps

Add a publisher view when the same Vue application needs to send camera or screen-share media.
Move host and stream configuration into a secure server-side flow rather than displaying raw connection values in the UI.
Add application-specific states such as a stream schedule, loading skeleton, no-live-stream message, and analytics events.
Use Red5 Cloud when you need a managed deployment, or review Red5 Pro when you need control over infrastructure, security, scaling, or deployment architecture.

For more browser implementation options, see Red5’s live streaming SDKs and WebRTC server resources.

Conclusion

Vue streaming with Red5 Cloud can be implemented as a focused Vue component: receive connection values, initialize a WHEP subscriber, attach it to a video element, and clean it up when the component or subscription ends. The Red5 Vue repository gives you a working starting point, including WHEP setup, status events, and optional retry behavior.

How to Create WebRTC Publisher Clients with Adaptive Live Encoding

Maria Artamonova — Sat, 12 Sep 2026 05:00:14 +0000

WebRTC adaptive bitrate control helps a live publisher keep streaming when network conditions change. We have a server-side ABR mechanism, which most customers use, utilizing transcoding. This is beneficial and more often used; however, it is tied to having a Stream Manager deployment and is more of a subscriber-side ABR (e.g., the server manages which stream to deliver to the subscriber based on the subscriber’s network conditions). This example is publisher-side ABR, delivering video to the server based on network conditions. The implementation is based on the Red5 WHIP Adaptive Bitrate Controller example.

This tutorial uses Red5 Pro, our self-hosted live streaming server software. The repository loads the Red5 HTML SDK and is designed to connect to either a standalone Red5 Pro deployment or Stream Manager 2.0. The SDK provides the browser-side publishing API, but it still requires a Red5 Pro server deployment to establish the WHIP session.

To follow this tutorial, log in to your Red5 Pro account. If you do not have an account yet, sign up for a 30-day Red5 Pro trial and use the resulting Red5 Pro deployment with the example.

Why Add WebRTC Adaptive Bitrate Control?

A WebRTC publisher may start with a strong connection and then encounter congestion, packet loss, or a sudden increase in round-trip time. If the sender continues transmitting at the same quality, viewers may see frozen video, dropped frames, or a failed publishing session.

WebRTC adaptive bitrate control responds by changing the sender’s encoding parameters while the session is active. A degraded state can apply a lower maximum bitrate and a larger resolution scale factor. After several healthy samples, the controller can restore the configured quality.

Monitor the connection continuously.
React to sustained degradation rather than one temporary spike.
Reduce outgoing video quality while preserving the session.
Restore quality only after the network has demonstrated recovery.

How WebRTC Adaptive Bitrate Control Works

The example publishes video with WHIPClient from the Red5 HTML SDK. Its configuration requests a statistics report every 1,000 milliseconds. Each report is passed to StatsMonitor, which processes the relevant outbound video and candidate-pair entries.

The browser exposes these reports through the RTCPeerConnection.getStats() API. The example receives equivalent data through the Red5 SDK’s stats event transport.

Build the WebRTC Stats Monitor

Start by defining thresholds for the conditions that should trigger a quality reduction. The example treats the network as degraded when any one of its high thresholds is exceeded. It requires three consecutive samples before changing state, which prevents a single transient spike from causing an unnecessary quality change.

const thresholds = {
PACKET_LOSS_HIGH: 5,
PACKET_LOSS_RECOVERY: 2,
RTT_HIGH: 0.3,
RTT_RECOVERY: 0.15,
PLI_FIR_RATE_HIGH: 3,
PLI_FIR_RATE_RECOVERY: 1,
CONSECUTIVE_SAMPLES_TO_TRIGGER: 3
}

These values are example defaults, not universal WebRTC requirements. Tune them with measurements from your own application, codecs, devices, and network conditions.

Detect Network Degradation

WebRTC statistics such as packetsSent, retransmittedPacketsSent, pliCount, and firCount are cumulative counters. Comparing their total values directly can make old network problems look like current problems. Instead, store the previous sample and calculate the difference between two reports.

calculatePacketLossRate(packetsSent, retransmittedPacketsSent) {
if (this.state.previousPacketsSent === null) {
this.state.previousPacketsSent = packetsSent
this.state.previousRetransmittedPacketsSent = retransmittedPacketsSent
return 0
}

const sent = packetsSent - this.state.previousPacketsSent
const retransmitted = retransmittedPacketsSent -
this.state.previousRetransmittedPacketsSent

this.state.previousPacketsSent = packetsSent
this.state.previousRetransmittedPacketsSent = retransmittedPacketsSent

if (sent <= 0) return 0
return (retransmitted / sent) * 100
}

calculatePliFirRate(pliCount, firCount) {
if (this.state.previousPliCount === null) {
this.state.previousPliCount = pliCount
this.state.previousFirCount = firCount
return 0
}

const pliRate = pliCount - this.state.previousPliCount
const firRate = firCount - this.state.previousFirCount

this.state.previousPliCount = pliCount
this.state.previousFirCount = firCount
return pliRate + firRate
}

In this implementation, PLI and FIR requests act as a sender-side signal that the remote endpoint is requesting keyframes. They are combined into a per-interval rate. The monitor also stores the current round-trip time from the candidate-pair report.

Change Bitrate and Resolution Without Renegotiation

When the monitor detects a degraded state, locate the video RTCRtpSender, read its current parameters, update the first encoding, and apply the new values. The WebRTC sender API supports changing encoding and transmission parameters with setParameters().

const videoTrackSender = publisher
.getPeerConnection()
.getSenders()
.find(sender => sender.track?.kind === 'video')

if (videoTrackSender) {
const parameters = videoTrackSender.getParameters()
parameters.encodings ??= [{}]
parameters.encodings[0].maxBitrate = 300 * 1000
parameters.encodings[0].scaleResolutionDownBy = 8
await videoTrackSender.setParameters(parameters)
}

This example lowers the maximum video bitrate to 300 kbps and scales the encoded resolution down by a factor of eight. The values are intentionally visible and easy to change. The setParameters() documentation explains the sender parameter model and browser considerations.

Complete Adaptive Bitrate Control Example

The following controller connects the monitor’s state changes to the WebRTC sender. It reduces quality after three consecutive degraded samples and restores the target bitrate and original scale after three consecutive healthy samples.

const TARGET_BITRATE = 2500 * 1000
const LOSSY_BITRATE = 300 * 1000

const getVideoTrackSender = () => {
return publisher
.getPeerConnection()
.getSenders()
.find(sender => sender.track?.kind === 'video')
}

const setVideoQuality = async (maxBitrate, scaleResolutionDownBy) => {
const sender = getVideoTrackSender()
if (!sender) return

const parameters = sender.getParameters()
parameters.encodings ??= [{}]
parameters.encodings[0].maxBitrate = maxBitrate
parameters.encodings[0].scaleResolutionDownBy = scaleResolutionDownBy
await sender.setParameters(parameters)
}

statsMonitor.setOnLossy(async ({ packetLossRate, rtt, pliFirRate }) => {
await setVideoQuality(LOSSY_BITRATE, 8)
console.log('Network degraded', { packetLossRate, rtt, pliFirRate })
})

statsMonitor.setOnRecovery(async ({ packetLossRate, rtt, pliFirRate }) => {
await setVideoQuality(TARGET_BITRATE, 1)
console.log('Network recovered', { packetLossRate, rtt, pliFirRate })
})

In the repository example, the monitor is connected to a WHIPClient configured to emit a WebRTC.Stats.Report event every second. The full working implementation also includes publishing, controls, status indicators, and event handling.

Test WebRTC Adaptive Bitrate Control

Test the controller with a real publisher and a separate subscriber. Start the WHIP stream, confirm that the normal bitrate and resolution are applied, then introduce packet loss and delay on the publishing device. The controller should enter the degraded state only after the configured consecutive-sample count is reached.

Open the example with the correct server, application, and stream parameters.
Grant camera and microphone permissions, then start publishing.
Watch packet-loss rate, RTT, PLI/FIR rate, bitrate, and outgoing frame dimensions.
Use a network-throttling tool such as Network Link Conditioner from Apple to introduce delay or packet loss on macOS.
Confirm that the viewer remains connected while the outgoing quality is reduced.
Restore the network and confirm that quality returns after the recovery sample count is reached.

Do not validate the feature only by watching the publisher preview. The important result is the end-to-end behavior: the subscriber should continue receiving video while the publisher adapts, and the stream should recover without a new publish session.

Tune Thresholds for Your Application

The repository’s defaults are a starting point for testing. They use packet loss above 5%, RTT above 0.3 seconds, or more than three PLI/FIR requests in an interval to identify degradation. Recovery requires packet loss below 2%, RTT below 0.15 seconds, and a PLI/FIR rate at or below 1.

Adjust the thresholds according to the application’s tolerance for quality changes and temporary instability. A stricter controller may react sooner but can change quality too often. A more tolerant controller may avoid unnecessary reductions but allow visible problems to persist longer.

const monitor = new StatsMonitor({
thresholds: {
PACKET_LOSS_HIGH: 8,
RTT_HIGH: 0.5,
CONSECUTIVE_SAMPLES_TO_TRIGGER: 5
}
})

monitor.setThresholds({
PACKET_LOSS_RECOVERY: 3,
RTT_RECOVERY: 0.2
})

Limitations and Next Steps

This implementation uses a simple two-state controller: normal quality and reduced quality. A production application may need a multi-step bitrate ladder, separate audio and video policies, codec-specific testing, subscriber-side measurements, or a coordinated server-side strategy.

Use more quality levels: Step through several bitrate and resolution combinations instead of switching directly between two states.
Measure the remote side: Consider remote-inbound-rtp data when receiver-side packet loss is important to the decision.
Protect against oscillation: Add cooldown periods or hysteresis so the controller does not move up and down too quickly.
Test browser differences: Verify scaleResolutionDownBy, encoder behavior, and sender parameters on the browsers and devices you support.
Separate policy from transport: Keep the monitoring logic independent from the publishing SDK so it can be adapted to another WebRTC workflow.

For broader WebRTC implementation context, see Red5’s WebRTC overview, WHIP and WHEP resources, and live streaming SDKs.

Conclusion

WebRTC adaptive bitrate control can be implemented in the browser by combining periodic WebRTC statistics with live sender-parameter updates. The essential pattern is to calculate delta-based metrics, require consecutive samples before changing state, reduce bitrate and resolution when the network degrades, and restore quality only after recovery is consistent.

Use the Red5 WHIP Adaptive Bitrate Controller example as a working starting point, then tune its thresholds and quality levels for your application. With that feedback loop in place, a temporary uplink problem can become a controlled quality reduction instead of a failed live stream.

AV1 vs AV2: Which Video Codec Should You Use in 2026?

Maria Artamonova — Fri, 11 Sep 2026 05:00:13 +0000

AV1 is the practical production choice in 2026. AV2 may ultimately deliver better compression and more flexible media experiences, but its newly finalized specification is only the starting point for optimized software, hardware, browsers, devices, packaging, and commercial deployment.

For most streaming teams, the decision is not AV1 or AV2 on equal terms. Use AV1 where its efficiency justifies the encoding and device-compatibility work. Treat AV2 as an evaluation target for codec development, hardware planning, and future services until its end-to-end delivery ecosystem matures.

AV1 vs AV2: The Short Answer

Choose AV1 when you need a royalty-free, efficiency-focused codec that can be deployed across an expanding ecosystem of software, browsers, devices, and streaming workflows.
Evaluate AV2 when you are planning for higher compression efficiency, multi-stream or multi-view experiences, screen content, AR or VR, or future codec deployments.
Monitor AV2 without adopting it prematurely when you want to understand its future potential but your service depends on mature encoders, decoders, hardware, players, and devices today.

What Are AV1 and AV2?

AV1, or AOMedia Video 1, is an open video codec released in 2018 by the Alliance for Open Media. It was designed for efficient internet video delivery under AOMedia’s royalty-free patent policy. AV1 now has production encoders and decoders, browser and operating-system support, hardware acceleration on many newer devices, and documented deployments by major streaming and communication services.

AV2, or AOMedia Video 2, is AV1’s successor, but it defines a new bitstream and decoding process rather than a backward-compatible AV1 profile or decoder upgrade. Version 1.0.0 was finalized on May 28, 2026, and publicly announced on June 9, 2026. It targets higher compression efficiency, scalable bitstreams, multi-stream and multi-view video, screen content, broadcasting, streaming, and real-time video conferencing.

A final codec specification is not the same as a production-ready delivery ecosystem. The final AV2 release gives implementers a stable technical target, and the AOMedia Video Model reference software is available. Optimized encoders and decoders, container bindings, hardware acceleration, browsers, operating systems, players, and shipping devices must still mature around it.

Who Already Uses or Supports AV1?

AV1 has been used in production for years. Major streaming platforms, communication services, device manufacturers, and software ecosystems have deployed or documented AV1 support. The AOMedia AV1 adoption showcase includes implementations from Google, Netflix, Meta, Microsoft, Vimeo, VideoLAN, and other organizations. These examples do not mean that every viewer receives AV1, but they demonstrate a real production ecosystem that AV2 does not yet match.

Netflix: Netflix reported in December 2025 that AV1 powered approximately 30% of all viewing on its service. Netflix also described AV1 HDR streaming and AV1 delivery across Android, smart TVs, browsers, and other large-screen devices. This is evidence of large-scale production deployment rather than a limited test. Read Netflix’s AV1 deployment update.
Meta: Meta has published results from AV1 deployment for Facebook and Instagram Reels, including a 12% average bitrate reduction and improved playback quality in one rollout. In 2026, Meta also reported at least a 20% bitrate reduction compared with H.264/AVC in offline real-time communication tests on low-end and mid-range devices. The results show why AV1 can be valuable for both stored video and real-time communication, while also highlighting the need to manage encoding complexity. See Meta’s Reels case study and Meta’s RTC update.
YouTube and Google: AOMedia documents AV1 use across YouTube, Chrome, Android, and Google Meet. This directly contradicts any suggestion that AV1 is still primarily a laboratory technology. It is part of a broad production platform ecosystem, although actual delivery still depends on content, client capability, and product policy. Review AOMedia’s Google adoption story.
Android and hardware manufacturers: Android added AV1 platform support in Android 10 and continues to improve software decoding for devices without dedicated AV1 hardware. Intel documents AV1 hardware decode support across newer processor generations, while Samsung introduced built-in AV1 playback support in its 2020 8K QLED TV lineup. Hardware coverage remains device-specific, but these examples demonstrate that AV1 playback is already available across important parts of the consumer ecosystem. Read Android’s AV1 support announcement, check Intel’s codec capabilities, and see Samsung’s AV1 announcement.

These deployments also explain why AV1 remains the practical codec for production decisions in 2026. Teams can test it against real devices, players, networks, and operational metrics. AV2 may ultimately improve compression and support more advanced media workflows, but it must first develop a comparable implementation and hardware ecosystem.

AV1 vs AV2: Side-by-Side Comparison

Compression Efficiency and Video Quality

Compression efficiency describes how much visual quality a codec can preserve at a given bitrate, or how much the bitrate can be reduced while maintaining a similar quality level. A published evaluation of the pre-final AV2 v13.0 development codec, using AV2 Common Test Conditions, reported a 29.81% BD-rate reduction with PSNR-YUV and a 33.79% reduction with VMAF under its random-access configuration, compared with its AV1 test anchor. These results are an important indicator of AV2’s potential, but they are not a benchmark of final AV2 v1.0.0 implementations. Review the AV2 evaluation methodology and results.

Those figures are controlled benchmark results, not a guaranteed saving for every source, product, or live workflow. Actual performance depends on content, resolution, frame rate, color depth, encoder implementation, preset, latency constraints, rate-control mode, and quality metric. The study also evaluated development software rather than mature commercial AV2 encoders. Teams should test representative footage with objective metrics and human visual review.

The practical promise is straightforward: AV2 may let a provider deliver the same quality with fewer bits, or improve quality without increasing the bitrate. That could reduce bandwidth and storage costs for large video libraries. It could also make high-resolution, multi-view, and immersive video more practical. The benefit will depend on whether the encoding and playback ecosystem can support the format efficiently.

Encoding, Decoding, and Hardware Support

AV1 adoption has been slowed by the cost of encoding, the need for hardware decoding, and uneven support across devices. Dan Rayburn’s summary of NETINT’s 2026 State of Video Encoding survey identifies hardware decode support, toolchain limitations, and encoding compute costs as the leading barriers to AV1 adoption. Those same operational questions matter even more when evaluating a newer codec.

AV2 now has a stable specification and reference software, which gives encoder and decoder developers a foundation for implementation. AOMedia says the next phase includes optimized software, broader hardware support, conformance testing, container bindings, and commercial product integration. The AOMedia implementation update explicitly says software implementations typically come first and that hardware support, which is essential for broad device adoption, follows.

Independent AV2 decoder development has begun. VideoLAN’s May 31, 2026 announcement described its first dav2d release as feature-complete for AVM v15, with 8-bit and 10-bit decoding and initial optimization work for x86, Arm, and RISC-V. VideoLAN also described the project as early work focused on correctness, conformance, optimization, and platform support. This is evidence of implementation progress, not final AV2 v1.0.0 conformance or broad production readiness.

AV2 Hardware and Ecosystem Signals in 2026

Early AV2 hardware activity is real, but the distinction between licensable decoder intellectual property and a shipping consumer device matters. Semiconductor IP announcements show that system-on-chip development can move forward. They do not prove that AV2 decoding is already available across production GPUs, phones, televisions, browsers, or streaming devices.

VeriSilicon: The company announced on June 9, 2026 that its VC9800D video processing unit IP supports AV2 decoding and had been provided to multiple customers.
Chips&Media: The company announced on June 10, 2026 completed AV2 hardware decoder IP and later disclosed a licensing agreement with an unnamed North American technology company. No shipping consumer product was identified.
Allegro DVT: The company announced real-time AV2 decoder IP in its Pulsar D400 series on June 16, 2026.

AV2 will also receive a formal industry update at IBC2026. The Coding the Future session, scheduled for September 12, 2026, includes an AOMedia update on AV1 and the newly published AV2 codec, followed by discussion of market impact and next steps. Andrey Norkin, Principal Architect at NVIDIA and co-chair of AOMedia’s Video Codec Working Group, is a confirmed speaker.

Features and Use Cases

AV1 is a strong fit for internet video delivery where bitrate efficiency, storage, and royalty-free codec access matter. Common use cases include video on demand, high-resolution streaming, mobile delivery, user-generated content, and adaptive bitrate ladders that serve AV1 to compatible clients while using a fallback codec for the rest of the audience.

AV2 keeps those goals and expands the design for more complex media. The official specification and AOMedia’s release materials describe support for scalable bitstreams, multiple synchronized streams, multiple camera angles, stereoscopic video, composite video, screen content, AR, VR, broadcast, and video conferencing. These capabilities can reduce the application-level coordination required to deliver related video components together.

AV2 may therefore be especially interesting for immersive experiences, interactive sports, multi-camera production, remote collaboration, and services that need to combine video components. The technology does not remove the need for application design, packaging, player support, or device testing. It provides a more flexible codec foundation for those workflows.

What Video Teams Are Using in 2026

Dan Rayburn’s report on NETINT’s 2026 State of Video Encoding survey shows why AV1 is worth evaluating before AV2 becomes widely available. Rayburn writes that AV1 has 17% current production deployment, while 40% of respondents plan to deploy it in 2026. Together, those figures represent a 57% combined reach by the end of the year, although they are survey results rather than a measurement of total market share. Rayburn describes this as mainstream planning rather than early-adopter experimentation.

NETINT sponsored the survey and distributed it through industry channels and its own network. Its sample may overweight organizations already evaluating hardware encoding, and APAC and LATAM are underrepresented. Treat the figures as directional evidence from the surveyed organizations, not a representative measure of the whole video market.

The survey also shows that codec adoption is connected to operational maturity. Organizations running three or more codecs in production are reported to be 57 times more likely to have AV1 in their stack than single-codec operators. Teams that already manage multiple encoders, device profiles, testing workflows, and delivery ladders are better positioned to add another codec.

The closest published survey covering AV2 comes from AOMedia itself. In September 2025, AOMedia reported that 53% of surveyed members planned to adopt AV2 within 12 months of finalization and 88% expected to implement it within two years. This measures roadmap intent among AOMedia members, not independent market share or confirmed product shipments, so it should be treated as an ecosystem signal rather than an adoption forecast.

The reported barriers to AV1 adoption are primarily operational. Hardware decode support leads at 54%, followed by toolchain limitations at 43% and encoding compute costs at 37%. Those findings reinforce the central lesson for AV2: compression efficiency alone does not determine deployment. Hardware coverage, tool maturity, encoding economics, packaging, playback support, and operational capacity determine whether a codec is viable at scale.

Which Codec Should You Use?

Use AV1 now if you need a more efficient delivery codec, your target clients support AV1, and your encoding infrastructure can meet the required throughput and latency.
Evaluate AV2 experimentally if you are researching immersive or multi-view experiences, developing codec technology, or want to understand its future capabilities. Evaluation is different from production adoption.
Keep a fallback if your audience includes older devices or your service requires predictable playback across many platforms. Codec ladders are usually more practical than a single-codec rollout.
Do not choose AV2 only from a compression claim. Compare the total system cost, including encoding, decoding, hardware, tooling, packaging, monitoring, playback, and support.

AV1 codec is now supported for ingest and egress streams across all protocols supported by Red5 Pro. AV2 support should be confirmed separately with each server, encoder, protocol, player, and device vendor because the codec’s first-generation ecosystem is still developing.

How to Evaluate AV2

Evaluating AV2 does not require an immediate migration or production rollout. Start by documenting your current codec stack, encoding presets, bitrate ladders, packaging formats, delivery protocols, player capabilities, device distribution, and quality metrics. This baseline will make future AV2 tests comparable and will show where the new codec could create value.

Next, create a test plan using representative live and on-demand content. Measure compression efficiency, encoding throughput, decoder performance, startup time, stream switching, latency, power use, playback stability, and infrastructure cost. Include the devices and network conditions that matter to your audience. Compare AV2 against your actual AV1 configuration, not only against a slow reference preset.

Before production adoption, require evidence of an optimized encoder and decoder, stable packaging and protocol support, browser or native-player integration, hardware coverage across target devices, conformance testing, monitoring, and a tested fallback. A reference implementation or hardware IP announcement can demonstrate progress, but neither proves that an end-to-end service is ready to replace AV1.

FAQs

Is AV2 better than AV1?

AV2 is designed to be more compression-efficient than AV1 and to support advanced multi-stream, multi-view, screen-content, AR, and VR workflows. However, AV1 has a more mature production ecosystem, broader hardware availability, and more proven deployment options. AV2 is technically newer, but it is not automatically the better operational choice for every service today.

What do AV1 and AV2 mean?

AV1 means AOMedia Video 1, an open video codec developed by the Alliance for Open Media. AV2 means AOMedia Video 2, its successor. AV2 defines a distinct bitstream and decoding process rather than a backward-compatible AV1 profile, while targeting higher compression efficiency and more flexible multi-stream, screen-content, broadcasting, and real-time workflows.

Is AV2 royalty-free?

AV2 was developed under AOMedia’s royalty-free patent policy, and AOMedia describes the specification as a royalty-free video coding standard. Organizations should still review the current patent policy, implementation terms, and legal requirements for their specific product. Royalty-free codec design does not remove the need for normal legal and technical due diligence.

Why is AV1 not more popular?

AV1 adoption has been slowed by hardware decoding coverage, toolchain limitations, encoding compute requirements, and uneven support across older devices. Its production use is growing, but deployment requires testing and operational work. AV1 is most practical when a team can control the delivery ladder, target compatible clients, or justify the efficiency gains at scale.

Conclusion

AV2 is a meaningful next step in open video coding. It is designed to deliver better compression efficiency than AV1 and to support more flexible multi-stream and immersive video workflows. The specification is now available, but the practical value of AV2 will depend on encoders, decoders, hardware, players, devices, protocols, and production tooling.

AV1 is the safer production choice for most teams in 2026. Use it where its efficiency and royalty-free design solve a real delivery problem, and measure the results across your actual devices, networks, and workflows. AV2 is worth tracking and evaluating, but its first-generation ecosystem is still far from broad production adoption.

CMSF vs. CMAF: What’s the Difference for Video Streaming?

Maria Artamonova — Thu, 10 Sep 2026 05:00:16 +0000

CMSF vs CMAF is not a choice between two competing media formats. CMAF defines a standardized way to package segmented media, while CMSF maps CMAF-packaged media into MOQ (Media over QUIC) workflows. In practical terms, CMSF carries familiar CMAF capabilities into a modern publish-and-subscribe transport architecture. That convenience can make CMSF attractive for adaptive bitrate streaming, content protection, and reuse of existing media workflows. However, applications that prioritize the lowest possible latency, including remotely operated drones, may benefit more from the lighter LOC container.

This guide explains the relationship between the formats, how CMSF works with MOQ, and how to choose between CMAF-based CMSF packaging and LOC.

CMSF vs CMAF: Quick Comparison

The central CMSF vs CMAF distinction is scope. CMAF specifies how media is structured. CMSF specifies how that CMAF structure is represented in an MOQ streaming workflow. LOC is included in the table because it is the lower-overhead packaging alternative that often determines whether CMSF is the right choice.

What Is CMAF?

CMAF, or Common Media Application Format, is a standardized media application format for segmented audio, video, subtitles, and related data. It is defined by ISO/IEC 23000-19 and builds on the ISO Base Media File Format. CMAF is a packaging format, not a transport protocol.

A CMAF presentation can contain multiple tracks representing different bitrates, resolutions, audio options, or languages. Compatible tracks can form a switching set, allowing a player to change representations as network conditions change. This supports adaptive bitrate streaming without requiring every delivery protocol to use a different copy of the encoded media.

CMAF is widely associated with HTTP delivery because the same fragmented media can be referenced by HLS playlists and MPEG-DASH manifests. Apple also documents how CMAF works with HLS. Reusing the same media objects can reduce duplicated packaging and storage while improving cache efficiency.

In a CMSF vs CMAF comparison, CMAF provides the underlying media structure. It does not by itself define MOQ subscriptions, tracks, groups, objects, priorities, or relay behavior.

What Is CMSF?

CMSF stands for CMAF-Compliant MOQT Streaming Format. The IETF CMSF Internet-Draft defines it as an extension of the MOQT Streaming Format for delivering CMAF- and LOC-compliant media over MOQ Transport. As an Internet-Draft, CMSF remains a work in progress and may change before publication as an RFC.

CMSF does not replace CMAF or create a separate codec. It describes how CMAF headers, tracks, fragments, chunks, switching sets, encryption information, and timing relate to the MOQ streaming model. The simplest way to understand CMSF vs CMAF is that CMAF supplies the packaging rules, while CMSF supplies the MOQ-specific mapping. This CMSF vs CMAF relationship lets the two specifications operate at different layers.

Each CMAF track in a switching set is carried as a separate MOQT track. CMSF requires those tracks to be time-aligned so a subscriber can move between alternative encodings without disrupting the presentation. Each MOQT object contains at least one CMAF chunk, and group boundaries align with CMAF fragment boundaries.

This design preserves capabilities familiar to CMAF workflows while making the media available through MOQ’s subscription and relay model. Red5 previously covered the evolution of CMSF, MSF, and LOC in its overview of the MOQ media layer player framework.

How Is CMSF Used With MOQ?

MOQ separates media transport from media packaging. The MOQT specification defines a publish-and-subscribe transport in which media is organized into tracks, groups, and objects and can be forwarded through relays. CMSF tells publishers and subscribers how CMAF-packaged media fits into those structures.

A publisher first exposes a catalog describing the available audio, video, or data tracks. CMSF catalog entries can identify codecs, bitrates, dimensions, frame rates, initialization data, alternative groups, and content-protection information. A subscriber can then request the tracks it needs instead of receiving every available representation.

For a multi-bitrate video presentation, each CMAF representation becomes a separate MOQT track. Matching alternative-group values indicate that the tracks belong to the same switching set. Time alignment enables the player to move from one bitrate to another, while MOQ handles object delivery and relay-based distribution. In this part of CMSF vs CMAF, CMSF connects CMAF’s alternatives to MOQT subscriptions.

CMSF maps CMAF representations to separate MOQT tracks, carries CMAF chunks in aligned MOQT objects and groups, and allows subscribers to request the tracks they need. Source: IETF CMSF Internet-Draft.

That division of responsibilities is central to CMSF vs CMAF: CMSF does not make CMAF “faster” on its own. It makes CMAF media usable within an MOQ architecture that supports selective subscriptions, prioritization, and modern relay distribution.

Why CMSF Is Convenient

The main advantage in the CMSF vs CMAF relationship is reuse. Organizations with CMAF-aware encoders, packagers, players, and protection workflows do not have to discard that model to experiment with MOQ delivery. CMSF carries established media structures into the newer transport environment.

Established DRM and Content Protection

CMSF supports content protection through ISO Common Encryption at the CMAF media layer.

Common Encryption schemes supported by CMSF. The current draft recommends CBCS for broader hardware-decoder compatibility. Source: IETF CMSF Internet-Draft, Table 3.

Its catalog can signal commercial DRM systems, including Widevine, PlayReady, and FairPlay Streaming, while encrypted samples remain compatible with content decryption modules and secure playback pipelines. The underlying browser model for protected playback is standardized through the W3C’s Encrypted Media Extensions.

This is more than a checkbox for premium video. Sports, entertainment, and licensed programming may require hardware-backed decryption, license acquisition, key rotation, and integration with established DRM services. CMSF can reuse those mechanisms rather than forcing an application to build protection solely at the application layer.

DRM systems identified in the CMSF catalog, including Widevine, PlayReady, FairPlay, and ClearKey. Source: IETF CMSF Internet-Draft, Table 4.

DRM reuse is one of the clearest practical benefits in a CMSF vs CMAF analysis.

Adaptive Bitrate Streaming

CMAF switching sets already provide a structured model for alternative encodings. CMSF maps these representations to aligned MOQT tracks, preserving the information a player needs to select an appropriate bitrate. That makes CMSF useful when changing network capacity matters as much as speed. Here, CMSF vs CMAF means transport mapping versus the original switching structure.

Live and On Demand Media

The CMSF draft targets both live and on demand content. A shared streaming format can therefore support a live presentation, delayed playback, and stored content without forcing every mode into a completely separate packaging system. This flexibility is one reason CMSF vs CMAF should be understood as an extension relationship rather than a replacement decision.

CMSF vs CMAF and LOC: The Latency Tradeoff

The convenience of CMSF comes with additional structure. CMAF relies on ISO BMFF boxes, initialization information, fragments, chunks, and timing rules. CMSF retains that structure and maps it into MOQ objects. Processing and buffering choices within this richer pipeline can add latency compared with a deliberately minimal container.

LOC, or Low Overhead Media Container, provides compact framing for encoded media samples. It is designed to work efficiently with WebCodecs and other applications that can consume elementary media with minimal container processing. Fewer packaging requirements can help an implementation move a captured frame from encoder to network and from network to decoder sooner.

However, LOC does not automatically provide every convenience associated with mature CMAF workflows. A team choosing LOC may need to do more application-specific work around packaging, playback, content protection, metadata, or interoperability. CMSF offers more existing structure; LOC offers a leaner path.

Neither specification guarantees a universal end-to-end latency number. Camera capture, encoding configuration, group-of-pictures length, network conditions, relay behavior, jitter buffering, decoding, and rendering all affect the result. The meaningful CMSF vs CMAF decision is therefore not “Which acronym is faster?” but “How much packaging convenience can this application afford before latency becomes unacceptable?”

Why Drones May Favor LOC

For entertainment streaming, a modest amount of buffering may be acceptable if it supports stable adaptive playback and strong DRM. For drone live streaming, every additional delay can affect how quickly an operator observes an obstacle, changes direction, or responds to a developing situation.

A remotely piloted drone, inspection robot, or teleoperation system often has a different priority order from an OTT service. Immediate visual feedback may matter more than compatibility with an existing fragmented-MP4 packaging chain. The device may also have limited compute, memory, power, or uplink capacity.

In those cases, LOC can be the better fit because its lower container overhead helps minimize work between encoding and delivery. This does not mean LOC always produces lower measured latency in every implementation. It means LOC removes packaging complexity that may be unnecessary for a latency-critical application.

CMSF can still make sense for some drone workflows. Recorded inspection footage may need encryption, multi-bitrate playback, archiving, and later on demand review. A system may even use LOC for the operator’s immediate control view and CMAF-based packaging for protected distribution or stored playback. This hybrid CMSF vs CMAF decision should follow the application rather than force every output through one path.

When Should You Use CMSF?

Choose CMSF when the application needs MOQ distribution and benefits from existing CMAF capabilities. Typical requirements include multiple bitrate tracks, established DRM integration, protected premium content, familiar ISO BMFF processing, or a consistent approach to live and on demand playback. For these priorities, the CMSF vs CMAF relationship preserves rather than replaces existing packaging.

In a practical CMSF vs CMAF evaluation, CMSF is appropriate when CMAF is already part of the media pipeline and MOQ is the desired transport. The format can reduce the amount of new packaging and player logic required to connect those two layers.

When Should You Use LOC?

Choose LOC when the smallest possible packaging layer is more valuable than compatibility with CMAF tooling. Strong candidates include drones, robotics, remote control, machine vision, real-time monitoring, and resource-constrained devices. These applications are also good candidates for ultra-low latency streaming, where delays below one second can determine whether interaction feels immediate.

LOC may also suit teams building directly around WebCodecs or custom media processing. The tradeoff is that developers must evaluate how they will handle features that a CMAF-based ecosystem already supports, especially content protection and established playback integrations. That implementation work belongs in every CMSF vs CMAF and LOC evaluation.

CMSF vs CMAF Decision Table

FAQs

Is CMSF the Same as CMAF?

No. CMAF is a standardized media packaging format. CMSF is an IETF work in progress that defines how CMAF-packaged media is carried within an MOQ streaming format. The answer to CMSF vs CMAF is therefore “MOQ mapping versus base media packaging,” not two interchangeable standards.

Does CMSF Require MOQ?

Yes. CMSF is specifically designed as a CMAF-compliant implementation of the MOQT Streaming Format. CMAF itself does not require MOQ and can be used with other delivery systems, including HLS and MPEG-DASH.

Does CMSF Support DRM?

Yes. The current draft supports CMAF content protection using ISO Common Encryption and catalog signaling for DRM systems such as Widevine, PlayReady, and FairPlay Streaming. Actual compatibility depends on the selected encryption scheme, device, player, license service, and content decryption module.

Is LOC Always Faster Than CMSF?

No specification guarantees that LOC will always achieve a particular end-to-end latency. LOC has less container overhead, which can make it preferable for latency-sensitive implementations. Actual performance depends on the entire capture, encode, network, relay, decode, buffer, and render pipeline.

Can One Application Use Both CMSF and LOC?

Yes. A system can select packaging according to the output. For example, it could prioritize LOC for a drone operator’s control feed and use CMAF-based CMSF tracks where DRM, adaptive bitrate playback, or on demand access is more important. This turns CMSF vs CMAF from a binary choice into a workload-specific design.

Conclusion

The essential CMSF vs CMAF relationship is straightforward: CMAF defines reusable segmented media packaging, and CMSF adapts that packaging to an MOQ streaming format. CMSF provides a convenient path to adaptive bitrate switching, established DRM ecosystems, and live or on demand delivery over MOQ.

That convenience is not free. For latency-critical applications such as drones, robots, and remote-control systems, LOC’s lighter framing may leave more room in the latency budget. The right choice depends on whether the application values mature packaging capabilities or the leanest possible path from encoder to decoder. Teams should test both approaches across the complete production pipeline rather than treating either format as universally superior.

Emerging Next-Gen 5G Streaming Architecture Has Major Implications for Content Providers

Maria Artamonova — Wed, 09 Sep 2026 20:00:00 +0000

Introduction

Amid 5G’s unrelenting gains as a conduit for video streaming, new developments taking shape with carrier conversions from Non-Standalone (NSA) to Standalone (SA) infrastructures have major implications for everyone streaming content through 5G connections.

Much has been written about the slicing capabilities associated with 5G SA as defined by 3rd Generation Partnership Project (3GPP) specifications. But there’s been far less focus on specifications defining 5G Advanced Media Streaming Architecture (MSA), which is integral to getting the best possible streaming performance with the use of dedicated virtual circuits created by slicing mechanisms.

Unlike how streaming works over wireline networks, where the media and transport layers operate independently of each other, 5G MSA as part of the latest specifications released by 3GPP under the 5G Advanced label, functionally integrates media and transport layers in ways that orchestrate how network components are used to support specific media applications. But 5G MSA isn’t a new streaming format.

Instead, it’s comprised of a hierarchy of application program interfaces (APIs) with elements controlling 5G network operations that provide third parties direct access to 5G SA functionalities that can be used to optimize support for their streamed content no matter what streaming format they’re using or what the use case might be. This means outsiders can maintain their positions as independent providers using 5G connectivity free of the best-effort dependency they’ve had to live with up to now or, alternatively, without the heavy lifting and costs they had to endure with one-off integrations to enable better QoS performance over each CSP’s infrastructure.

Paralleling the motivations that spawned the open-source software movement, communications service providers (CSPs) serving as mobile network operators (MNOs) and often using 5G as a fixed wireless access (FWA) pipeline are relaxing the proprietary controls they have long exercised in creating their own, largely failed high-performance streaming services. The 5G MSA initiative is just a piece of a larger 5G Advanced agenda aimed at making 5G mobile and FWA a far more inviting environment for third parties to work in, which is CSPs’ best hope for making the investment in 5G worthwhile, according to a report issued by McKinsey & Co.

“Although telcos invested nearly $1 trillion in network upgrades since 2018, they are still struggling to monetize 5G,” McKinsey wrote. “The sector is now at risk of losing out on the chance to extract significant value from 5G’s unique capabilities, much as it has missed the opportunity from streaming video and enterprise messaging over the past 20 years.”

By relying on monetization models that leverage the new API ecosystem emerging with 5G Advanced, CSPs have the potential between now and the 2029-2031 timeframe to “unlock $100 billion to $300 billion in connectivity- and edge-computing-related revenue for operators while generating an additional $10 billion to $30 billion from APIs themselves,” the report said. However, as McKinsey also suggests, if CSPs don’t proceed aggressively with building out the supporting elements, including deal-making templates as well as the API infrastructure, up to two thirds of that value creation could go “to other players in the ecosystem, such as cloud providers and API aggregators.”

In other words, one way or another, the marketplace unfolding through 5G Advanced and MSA is a wide-open global gold mine that’s sure to redefine the wireless business as it’s been structured up to now. “In addition to enhancing today’s use cases, network APIs can lay the foundation for entirely new ones,” McKinsey said.

“Remotely operated equipment, semi-autonomous vehicles in production environments, augmented reality gaming, and other use cases could create substantial value in a broad range of industries,” the report continues. “By enabling these innovations, telecom operators can position themselves as essential partners to enterprises seeking to accelerate their digital transformations.”

The implications are profound for everyone putting video streaming to commercial use, including entities in the M&E market who are used to concentrating on wireline broadband as their primary routes to end users. With the higher bitrates and more reliable coverage enabled by 5G New Radio (NR) technology, MSA has the potential to tilt streamed-media user experiences in favor of wireless over wireline access.

Consequently, from a content provider perspective, 5G should no longer be thought of as just a mobile technology. It’s also a force to be reckoned with when it comes to reaching devices, including handsets, that are connecting over fixed access networks, which is invariably the case when users aren’t out and about.

Our purpose here is to explain 5G MSA and its implications for the streaming ecosystem at large while describing Red5’s role in ensuring customers the maximum operational efficiency they’ll need as they exploit opportunities in the multi-faceted streaming environment to come. We begin with a look at where things stand today with the use of 5G mobile and FWA infrastructures in video streaming.

Part 1 – The Accelerating Impact of 5G

Recent research reports offer varying assessments of global video streaming market size and how market share is divided across service categories and user devices. But they all agree the market is booming with no end in sight. In Figure 1 we’ve cited findings from two sources that fall within consensus ranges on these points.

Figure 1. Video Streaming Statistics. Sources: Precedence Research; Mordor Intelligence.

The Global 5G SA Buildout

While, according to Ericsson’s latest Mobility Report issued in conjunction with the Global Mobile Suppliers Association (GSA), the global 5G subscriber count has surged to 3.1 billion in the seven years since 5G rollouts began in 2019, up to now video streaming as experienced by the vast majority of those subscribers has primarily been distinguished by the visual quality gains enabled by higher 5G bitrates. But that’s beginning to change at an accelerating pace as carriers move beyond the non-standalone (NSA) 5G implementations that have dominated the early years (see Figure 2).

Figure 2. Metrics Related to 5G Standalone (SA) Deployments.

Sources: Ericsson Mobility Report, June 2026; 5G Standalone, December 2025, GSA; Opensignal, 5G Standalone State of Play.

5G NSA functionality is limited by the fact that deployments rely on existing 4G LTE Evolved Packet Cores (EPCs) to support 5G radio access networks (RANs). In contrast, 5G SA requires a major rebuild extending from installation of new EPCs to placement of small cell access points deep enough in service areas to minimize high-traffic congestion and to accommodate the shorter signal reach associated with MNOs’ use of spectrum in the millimeter band above 20 GHz.

According to the GSA report cited in Figure 2, mobile and FWA device manufacturers are rapidly expanding support for 5G SA with 2,518 different device models now commercially available, marking a 33.7% increase from YE 2024. GSA notes many employ new chipsets like MediaTek’s Dimensity 9500 and Qualcomm’s Snapdragon 8 Elite Gen 5 to strengthen support for advanced features.

Anchored by a cloud-native 5G Core, 5G SA enables faster, more agile service orchestration with greater spectral efficiency generating higher uplink and downlink data rates. Key benefits include a reduction in latency contributions of RAN processing to 1ms through what’s known as Ultra Reliable and Low Latency Communications (URLLC), wider coverage through multi-spectrum band aggregation, and in slicing entailing delivery of logically independent virtual circuits within and across spectrum bands with the ability to customize performance parameters for multiple use cases.

The FWA Factor

Things have moved far enough with 5G SA buildouts to merit a close look at what a global 5G foundation means to the broadband services market, considering how rapidly 5G FWA is being positioned to compete with wireline networks (see Figure 3). For the first time, FWA has the potential to match the performance parameters achieved over wireline networks, including fiber-to-the-premises (FTTP) connections.

Figure 3. The Pace of 5G FWA Networking Worldwide.

Sources: Ericsson Mobility Report, June 2026; Ericsson Mobility Report, November 2025.

Our point here isn’t to make a case for 5G FWA versus other broadband access technologies or to suggest which ones will gain the most subscribers in the years ahead. Rather, we simply want to emphasize how important the 5G Media Streaming Architecture (MSA) emerging with 5G Advanced implementations over 5G SA networks will be to providers of streamed video in the consumer marketplace as they seek to maximize their market reach and flexibility in the years ahead.

As researcher Opensignal notes in a recent report on mobile 5G performance, “Direct to device (D2D) service only takes effect when a user is outside the range of traditional terrestrial networks.” In other words, 5G performance metrics that matter relating to consumer media consumption as compiled by Opensignal “primarily reflect every day on-network usage.”

Consequently, before diving into the details of what’s entailed with 5G MSA, it makes sense to take a look at where things currently stand with 5G FWA performance as measured against the other fixed access platforms, recognizing the FWA metrics will get better, not only with implementations of 5G Advanced capabilities but especially with the availability of more spectrum. As Opensignal says in its mobile report, “While nationwide 5G SA availability is a necessary foundation for advanced services, it has a more limited impact on user experience metrics than gains in spectrum depth or network capacity.”

Currently, FWA performance in the U.S. and elsewhere is restricted by MNOs’ prioritization of their operationally optimal mid-band holdings for mobile usage, leaving much of the current 5G FWA coverage impeded by the propagation distance limitations imposed by reliance on higher frequencies allocated to them at the 6 GHz tier and the millimeter wave frequencies above 20 GHz. But regulators worldwide, recognizing the need to leverage low-cost FWA to extend broadband into underserved areas, are moving to free up more spectrum in the lower tiers.

In the U.S., FWA performance could improve dramatically in the years ahead, depending on which MNOs benefit from winning bids in the Upper C-Band spectrum auction the FCC has slated for July 2027. The commission intends to auction eight 20 MHz upper C-band blocks between 3.98 and 4.14 GHz for what it calls “terrestrial wireless flexible use” under licensing that would allow seamless integration with winning bidders’ lower C-band block holdings. This would create an integrated 440 MHz “super band” with 3,248 flexible use licenses tied to specific service areas across the country.

While other U.S. carriers have indicated varying degrees of interest in FWA as a backup to wireline broadband, T-Mobile, billing itself as the “un-carrier,” is the only one among the big three who’s all in on FWA at this point. Lightreading recently reported the carrier has updated its FWA signup projections with anticipated growth from 8.5 million subscribers at YE 2025 to 15 million by 2030.

With a FWA footprint covering 70 million U.S. households, T-Mobile was outpacing all other providers in broadband subscriber growth as of Q1 2026, according to the industry trade publication RCR. Given the intensity of competition and the much higher costs of deploying FTTP, it remains to be seen whether Verizon and AT&T will stick to their fiber-centric agendas. But T-Mobile CEO Srini Gopalan was right about FWA when, as reported by Lightreading, he said, “The days of asking the question, is this here to stay? Those are gone.”

No matter how things go in the U.S., as reflected in Figure 3, FWA deployments are surging worldwide. Factoring in performance gains that will be coming into play with implementations of 5G Advanced, it’s safe to say that any comparison of how 5G FWA currently stacks up against wireline broadband will soon be outdated. But a look at what’s already been accomplished with FWA does offer a hint of what’s in store.

According to metrics Opensignal has compiled covering broadband deployments (Figure 4), while there are significant gaps between T-Mobile and the other top U.S. broadband providers in the case of downlink and uplink speeds, the differences across all the other measurement categories are amazingly small, including most dramatically video experience, where just 3.3 points on a 1-100 scale divide the top ranked Xfinity wireline network and T-Mobile’s FWA network. Similarly, the gap in consistent quality between Xfinity at the top and T-Mobile in last place is just 4.9 points.

Figure 4. Fixed Network Connectivity Performance in the U.S. (Opensignal Rankings and Scores).

Source: Opensignal Fixed Broadband Experience Report.

Another aspect to how close 5G FWA is to the wireline side can be seen in reliability scores measured on a different scale, where all five providers are above 600. According to Opensignal, 600+ scores line up with user-generated assessments of their home internet connections as highly reliable, which, the researcher says, “means the connection has either never dropped or dropped very infrequently and service has been sufficient for usual activities almost all the time.” Opensignal said T-Mobile’s score was up 58 points from a year earlier.

Part 2 – 5G Advanced & Media Streaming Architecture

Now with growing numbers of carriers worldwide reporting they have reached high levels of 5G SA coverage on mobile and FWA networks, the next step is implementation of 5G Advanced. All the benefits achievable with 5G SA are aggregated for application with 5G Advanced under the set of 3GPP specifications in Releases 18 and 19, the last of which were published in 2025.

While the software stacks supporting 5G Advanced have already been deployed by some carriers, including T-Mobile, which in April 2025 announced it was the first to implement 5G Advanced architecture nationwide, it’s only now in 2026 that the marketplace can begin witnessing what this means in real-world operations. But the changes will be felt quickly, especially in the case of 5G FWA networks.

5G Advanced and the Coming of 6G

By virtue of operating in fixed mode as opposed to the more operationally complex mobile environment, implementations of 5G Advanced over FWA are easier and less costly to accomplish, which, according to the Opensignal report cited in Figure 2, means that carriers installing 5G Advanced support are largely focused on FWA, often leaving the mobile use case activations for later. With 5G Advanced in operation, these networks pose a significant threat to wireline operators with service orchestration intelligence delivering live-streamed user experience (UX) that’s hard to match in the wireline domain.

Indeed, what’s taking shape will likely serve as a foundation for media operations over both fixed and mobile 5G networks well into the future. That includes the 2030s when 6G specs are activated to put 5G Advanced to work in new ways by moving beyond use of AI as an add-on feature.

5G Advanced is becoming the industry baseline, and its service-based, cloud-native core is why it lasts: 3GPP is evolving that same core toward 6G rather than replacing it wholesale. For streaming providers, that makes it a durable foundation for converged delivery across cellular, fixed wireless, broadcast, and non-terrestrial networks.”

– Andrew Towe, 5G Broadcast and Media Streaming Standards Specialist.

Once 6G is up and running on that 5G Advanced foundation, cloud-native AI integration with network intelligence will allow the network to learn and adapt in response to changing use-case dynamics. And, as new spectrum allocations open space for implementations of 6G RAN usage for better performance at the millimeter wave and other spectrum tiers, the 5G spectrum sharing enabled by Dynamic Spectrum Sharing (DSS) will be expanded to include 6G via the new Multi-Radio Access Technology Spectrum Sharing (MRSS) mode that’s now part of the 5G Advanced specs.

As currently defined, 5G Advanced encompasses a wide range of capabilities that combine with the MSA specifications to create a high-potency video streaming environment, starting with the application-specific flows enabled by slicing. Slicing allows MNOs to get past the inherent unpredictability of wireless connectivity by meeting the high-performance requirements of circuits where there’s a payback for the extra effort that goes into that.

This brings into play as-needed utilization of advanced capabilities like low-latency, low-loss, scalable throughput (L4S), DSS and MRSS, and dynamic resource allocation to AI applications, which, as mentioned, will be operated from the core EPC with 6G. Notably, some 5G Advanced functionalities are well-tuned to delivering support for immersive services tied to extended reality (XR), cloud gaming and video communications interactivity during live events.

The 5G Media Streaming Architecture

All of this dovetails with 5G MSA, which frees content providers from having to negotiate proprietary CSP integrations if they want to benefit from the stream-specific applications of 5G Advanced. Now CSPs have a standardized approach to facilitating such engagements with the modular flexibility to build collaborations around which of the many functions relating to QoS, CDN-equivalent features, traffic handling and other features are activated through the platform’s APIs in either unicast or broadcast/multicast modes.

In the case of QoS, the specifications have gone to a level of network control granularity that manages the IP packet sets comprising individual video frames with enhancements in traffic detection and QoS flow mapping. In what is called “Content Hosting,” the specifications enable use case-specific control over ingest protocols and formats, caching and proxying of media objects, content preparation, access protection, and determining target distribution areas (e.g. through geofencing). And, with regard to trafficking, the technology delivers more information on traffic patterns related to timing, end of data bursts and other dynamics while extending the ability of user equipment (UE) to manipulate traffic handling policies during an ongoing streaming session.

All of this is accomplished through functionalities segmented for downlink and uplink implementations on CSP networks with minimal disruption to content providers’ streaming platform workflows. The essential ingredient is, those providers need to have access to all the APIs third parties are supposed to use as the means of interacting with any MNO network that has been equipped to support 5G MSA.

Once they’re able to use those APIs, the software modules can be employed for any streaming scenario based on terms negotiated with individual MNOs, from mass market M&E deployments to use cases beyond mainstream consumer video applications, such as smart city, industrial and emergency surveillance, remote healthcare, education, working training, robotics and much else. We’ll delve deeper into the API aggregation processes in Part 3.

Here we’re focused on how 5G MSA works.

As illustrated in the accompanying diagram (Figure 5), which is devoted to downlink operations but can be applied to uplinks as well, the 5GMS-Application Function (AF) and Media Server (MS) residing in the carrier’s 5G core network interact via open APIs with the content supplier, labeled 5GMS-Application Provider (AP), to capture information describing the encoding, rights management, packaging, metadata and other elements defining performance parameters in the provider’s application layer.

The 5GMS-AF triggers provisioning of media session policies by the 5G system’s Policy Control Function (PCF) and network responses pertaining to managing QoS and traffic steering through the system’s Network Exposure Function (NEF). At the same time, the 5GMS-AF conveys the AP’s data set to the 5G Client’s Media Session Handler, which coordinates setting up and managing sessions and collecting quality of experience (QoE) and consumptions metrics on the User Equipment (UE).

The same application layer data is transmitted from the 5GMS-AP through another API to the 5GMS Application Server (AS), which communicates directly with the 5GMS Client’s Media Player to fetch and play the media stream. The actual moment-to-moment operations of the session stream are enabled by the logic conveyed by the AP through a streaming service known as the 5GMS-Aware Application.

Messaging also flows through many other designated interfaces to coordinate:

configuration and provisioning between AF and AS,
ABR profile selection and other media player processes,
content protection,
processing and caching by CDNs or 5G’s Edge-enabled 5GMS Application Server (EAS),
performance monitoring,
and much else specific to the streamed session requirements on downlinks and uplinks.

Figure 5. 5G Media Streaming Architecture: Downlink Operations. Source: 5G Media Action Group.

In this diagram illustrating the downlink operations of 5G MSA, the 5G platform is linked to the content provider, identified as the Application Provider, through two M-labeled APIs – one (M1) to the Application Function (AF) that provides messaging pertinent to the 5G Network (NEF), the Policy Configuration (PCF) and the client-side Media Session Handler, and the other (M2) to the Application Server (AS) that communicates via the M4 interface with the client-side Media Stream Handler. Coordination between the 5GMS AF and AS is maintained by communications over the M3 interface, while the other M-labeled interfaces support messaging among components in the 5G client residing in the User Equipment (UE).

The Real-Time Communications Architecture Component in 5G Advanced

Adding to the new standardized approach to optimized streaming over 5G, 3GPP has introduced specifications supporting real-time video communications with the use of WebRTC. Referenced as Real-time Media Communications Architecture (5G-RTC), the idea is to use the same architectural elements defined by 5G-MSA for RTC, substituting RTC Application Provider for Media Application Provider with the RTC AF as one realization of the general Media AF and similar roles accorded to the RTC AF, RTC Client, and Native WebRTC App vis a vis, respectively, the Media AF, Media Client and 3rd party Media-Aware Application.

From an architectural perspective, the biggest difference is that, with 5G-RTC, the Client is an end point in WebRTC connectivity that is supplied by the Application Provider. But, essentially, the idea is to provide users a two-fold path to incorporating their WebRTC into 5G streams: either as standalone real-time communications services or as real-time peer-to-peer communications adjuncts to general streaming applications that employ of 5G MSA.

In all cases, 5G-RTC is meant strictly as a way to support use of WebRTC in 5G networks in conformity with the basic standard with no intention to integrate the architecture with platforms like the Red5 Experience Delivery Network (XDN) that use additional techniques to enhance scaling and applications versatility with WebRTC. But 3GPP has taken another step toward bringing 5G together with highly scalable real-time streaming as supported by XDN Architecture and the world at large through implementation of rudimentary support for the MOQ Transport standard.

In this case, the latest 3GPP 5G Advanced specifications make it possible for the 5G system to obtain metadata pertaining to MOQT operations from encrypted traffic. This automates MNOs’ ability to treat the content as MOQ traffic in cases where they have configured what’s known as user plane functions in their networks to support MOQ relay functionality. Otherwise, as mentioned earlier, content packaged for streaming over MOQ will be treated at the media layer when it comes to delivery over 5G networks like all other streamed media with the 5G Advanced options available to 3rd parties in cases where MNOs have implemented 5G MSA.

Part 3 – Enabling 3rd Party Use of 5G MSA

There are many approaches streaming application providers can take to equipping themselves with the APIs they’ll have to use in unlocking the capabilities of the 5G MSA. While a rudimentary API ecosystem, including contributions from CSPs themselves, has emerged as part of the generalized Programmable Network Architecture established for 5G SA, the APIs central to executing the elements described in Figure 5 for 5G MSA have yet to become a significant segment of that ecosystem.

The Emerging CSP API Ecosystem

Up to now, the mobile industry’s collaborative focus has been on development of a 5G Advanced API ecosystem that’s primarily meant for enterprises operating over private 5G networks. That activity is organized through two initiatives, beginning with coordination of API development by the Linux Foundation’s CAMARA project. Once certified for commercial use, the APIs are made available to users through the GSMA Open Gateway23 Initiative.

All three of the top U.S. mobile carriers along with Orange, Telefonica and Vodafone and two vendors, Ericsson and Nokia, comprise the Premier membership tier of CAMARA. These CSPs and most other major carriers globally are participants in the GSMA Gateway

These initiatives attest to how important private networking has become to monetizing CSP infrastructure. The rapid spread of private 5G networks leverages the core infrastructure built by CSPs either with local access extensions dedicated entirely to enterprise uses or through shares of the public 5G access network capacity that are dedicated for private use.

Most APIs offered so far through GSMA Gateway23 are targeted to generalized applications like authentications, location services, real-time communications, QoS profiling and connectivity, device information, computing services and financial arrangements rather than the APIs specifically defined for 5G SMA. Commercially viable use cases enabled by these APIs that have gone into play since 3GPP issued its final set of 5G Advanced specs involve things like autonomous vehicle operations, fraud detection in insurance claims, airport general operations, security and baggage handling, delivery service operations and retail store connectivity. The three exceptions with M&E implications have to do with edge network detection for immersive game playing and support for immersive large events and remote venue connectivity.

Unmet Broadcaster Demand for 5G MSA APIs

But when it comes to facilitating use of APIs for 5G MSA operations over public networks, efforts on the part of CSPs have been sporadic at best. Nonetheless, it’s inevitable there will be a need for aggregations of 5G MSA APIs that eliminate burdensome DIY development now that CSPs have reached the point in their buildouts where they can pursue shared public network opportunities enabled by the 5G Advanced specifications.

One immediate source of demand pushing carriers toward support for 5G MSA is the transition by over-the-air TV broadcasters worldwide to the next-gen transmission capabilities embodied in standards like ATSC 3.0 and DVB-1, which support delivery of streamed mobile video paired with TV channels over the TV broadcast spectrum. This is enabled by 5G Advanced specifications that extend reception of mobile services to standalone receivers used for over-the-air reception of next-gen TV signals.

According to a market report on global 5G developments produced by researcher IMARC Services, field trials leveraging 5G NR technology led by Qualcomm and German electronics giant Rohde & Schwarz across the U.S., U.K., Germany, and South Korea have created premium opportunities for free-to-air mobile TV that are now in various stages of implementation. The researcher cites ATSC 3.0 as a primary growth driver for 5G NR technology in the U.S. and notes 5G broadcasts unrelated to TV broadcast are utilizing the new specifications across China and India.

Part 4 – Red5 Support for Capitalizing on 5G Advanced

As of mid-2026, it’s too soon to assess exactly where all this will lead once 5G MSA is activated on 5G networks. But as CSPs move in that direction, our commitment at Red5 is to make access to 5G MSA readily available to our customers in whatever way or ways best serve their interests.

Building on Long-Standing Engagements with 5G Use Cases

This is an expansion of the agenda we’ve long pursued to maximize the benefits Red5 customers can attain reaching end users over 5G networks. One facet of these endeavors has to do with creating a real-time user experience with content streamed by sports and other live event producers to in-venue audiences.

Providers of in-venue viewing experiences, including The Famous Group and multiple sports and concert producers across the U.S. and beyond, are leveraging XDN Architecture to deliver a wide range of approaches to in-venue streaming. They’re using the Red5 platform to stream camera flows and feature enhancements, including augmented-reality (AR) experiences in many instances, from production centers to 5G and other in-venue wireless access points for A/V distribution to handhelds in perfect sync with what’s unfolding live.

On another track, Red5 is facilitating ultra-low latency streaming over 5G through connectivity of live-streamed content to 5G sites directly linked to the AWS global cloud via AWS Wavelength Zones. As the only real-time streaming supplier authorized for pre-integration with Wavelength, Red5 makes it possible for streamed content to avoid delay-producing internet hops in transit to the 5G data aggregation centers serving as AWS on-ramps.

Now, given all the developments discussed so far, it’s clear there’s a need to facilitate use of 5G MSA with the platforms we’ve developed to unify stream orchestration, packaging and playback for next-gen streaming operations in the complex multi-transport environment. Whether we do this through in-house MSA API development and aggregation, engagement with third party suppliers, or with deference to availabilities from CSPs depends on what will work best for our customers once CSPs begin activating 5G MSA.

The Red5 Universal Streaming Environment

Meanwhile, we’re proceeding with all the other initiatives we’ve announced over the past year that contribute to the multi-protocol streaming platform we’ve created with our support for the new MOQ standard. Where MOQ is concerned, we are working with a growing number of customers who are beta testing operations over the global CDN infrastructure instantiated with our partner CacheFly.

With the IETF nearing completion of the foundational MOQ Transport standard, we’ll soon be moving to commercial operations as we continue to expand our affiliations in the buildout of next-gen CDNs. In so doing, we’re prioritizing setups with CDN partners that will leverage XDN Architecture in the orchestration of cloud processing resources to enable point-and-click activation of streaming over any of the leading streaming protocols, including the currently prevailing HLS and DASH modes as well as the leading real-time streaming platform WebRTC.

With MOQ we’re opening the door to a less complex and, we anticipate, soon to be more widely adopted approach to what we’ve accomplished with WebRTC in enabling customers to stream payloads multi-directionally at any distance and scale with end-to-end latencies registering at 250ms and under. Along with benefitting from the dynamically adjustable latency levels enabled by MOQ, which, along with sub-500ms real-time streaming include streaming in the two-second and five-second latency ranges, Red5 customers utilizing these next-gen CDN infrastructures have the flexibility to transform ingested HLS- and DASH streams for transmission over MOQ to end users or to convert MOQ to the HTTP formats at CDN outputs to end users.

Moreover, they have access to the same wide array of TrueTimeTM application toolsets that have streamlined our customers’ ability to mount the many use cases associated with real-time streaming. These include TrueTime MultiView™, TrueTime WatchPartyTM TrueTime Meetings™, TrueTime Datasync™, and TrueTime StudioTM , all of which can be applied on the managed Red5 Cloud or DIY Red5 Pro infrastructures.

Paralleling the real-time transport versatility, we’ve taken our commitment to multi-format flexibility into the media layer with introduction of the Red5 Video Packager and our Playa client player, which can be employed in any streaming environment whether or not transport is provided by Red5 and its CDN partners.

As described in this blog and at greater depth in this white paper, the Red5 Video Packager is a cloud-mounted software platform used in conjunction with our transcoding technology to orchestrate use of cloud resources to handle the processing that goes into preparing payloads for ingestion onto origin servers for distribution over CDNs. This ultra-low latency processing and cost-saving cloud resource orchestration achieves desired results no matter whether payloads are streamed via HLS, Low-Latency HLS, MPEG-DASH, Low-Latency DASH, WebRTC, MOQ or RTSP.

Playa, which the OpenMOQ Software Consortium has endorsed as a template that can be used to develop players suited to any MOQ use case, can be used for playback of conventionally streamed content as well as content streamed over our MOQ Transport implementations. Or customers using the Red5 Video Packager in other streaming environments can rely on any other players suited to whatever streaming modes they’re using.

Conclusion

With all the opportunities embodied in the explosion of technologies aimed at adding new dimensions to streaming performance over mobile and fixed networks, providers of streaming services and applications face unprecedented levels of complexity on the road to exploiting these new capabilities. CSPs’ forthcoming activation of 5G MSA allowing third parties to leverage the integration of network and media layer functionalities in support of any use case will significantly add to both the opportunities and complexities providers face in the years ahead.

Red5, with its expansion of real-time streaming support into the new MOQ domain and introduction of a packaging platform supporting any streaming format, has already gone a long way toward eliminating the complexities endemic to operating in the next-gen streaming environment. We’re bringing the same commitment to saving time and cutting costs into our preparations for the availability of 5G MSA.

As our customers shape strategies aimed at enhancing streaming performance through the power of integrated network and media layer functionalities over both FWA and mobile 5G networks, they can be sure they’ll be able to take advantage of these capabilities with maximum efficiency on the converged streaming platform we’ve introduced with the Red5 Video Packager. Stay tuned as we update you on these developments and feel free to contact us any time for more information.

MOQ Video Streaming for Robots, Drones, and Embedded Devices: Powering the Next Generation of Connected Machines

Maria Artamonova — Wed, 09 Sep 2026 17:31:56 +0000

When people think about MOQ ( Media over QUIC), they usually picture live sports, entertainment, or interactive broadcasts. Those are important markets, but some of the protocol’s most interesting opportunities may come from robots, drones, and other embedded devices.

A drone inspecting power lines, a robot entering a burning building, an underwater vehicle examining offshore infrastructure, and a remotely operated medical system all depend on timely video. However, the video may need to reach far more than one remote operator. Command centers, subject-matter experts, AI models, recording systems, and other authorized viewers may all need access to the same feed. That combination of real-time performance, one-to-many distribution, and support for multiple types of subscribers is where MOQ could become the missing link.

Why Robots and Drones Need More Than a Point-to-Point Video Link

Remote devices often begin with a simple requirement: send video from a camera to an operator. Real deployments quickly become more complex.

Consider a drone used during a wildfire. The pilot needs a responsive feed to navigate safely. Incident commanders may need the same stream for situational awareness. An AI service may analyze frames for smoke, people, or changing fire boundaries. A remote specialist may join to assess infrastructure damage, while the full stream is recorded for later review.

The same pattern appears in many industries:

Public safety robots can send video to operators, incident commanders, and remote specialists.
Industrial inspection drones can share feeds with engineers, asset owners, and AI defect-detection systems.
Autonomous or remotely operated vehicles can deliver video and sensor data to control centers and fleet-management platforms.
Agricultural drones can stream crop imagery to operators and computer vision systems.
Underwater vehicles can connect offshore crews with experts located anywhere in the world.
Broadcast drones can supply live production feeds while creating recordings for replays and highlights.

In each case, a single device may produce video that needs to be consumed live, processed by machines, recorded, replayed, and distributed to multiple locations. A point-to-point connection alone does not address the entire workflow.

Where Current Streaming Protocols Fit

Robots, drones, cameras, and embedded devices commonly use protocols such as RTSP, SRT, RTMP, or WebRTC. These protocols remain useful, and MOQ should not be presented as an immediate replacement for all of them.

RTSP is widely used by IP cameras and other connected devices, but browsers do not play RTSP streams natively. A platform typically needs to ingest the feed and convert or restream it for browser playback and broader distribution.

SRT is designed to deliver reliable, low-latency video over unpredictable networks. Its configurable latency buffer allows retransmission of lost packets, but every workflow must balance additional recovery time against responsiveness. SRT is especially valuable for contribution links, although scaling a feed to many different consumers generally requires additional streaming infrastructure.

WebRTC provides real-time browser communication and is already proven in interactive applications. However, it also brings connection-establishment components such as ICE, STUN, and TURN. H.264 is supported in WebRTC browsers, contrary to a common misconception, but interoperability can still depend on compatible H.264 profiles, levels, and packetization modes between an embedded encoder and the receiving endpoint. In some workflows, the stream may still need to be repackaged or transcoded.

These technologies solve important parts of the problem. The opportunity for MOQ is to create a more unified path from contribution through distribution, processing, and playback.

What Makes MOQ Interesting for Embedded Devices

The current IETF Media over QUIC Transport draft defines a publish-and-subscribe protocol that operates over QUIC or WebTransport. Publishers produce data, intermediate relays can subscribe to this data and can forward it on to subscribers who request it. That model maps naturally to device-based video workflows.

One Published Feed Can Serve Many Subscribers

A robot or drone could publish its feed once to the nearest MOQ relay. The relay architecture could then deliver that content to authorized subscribers rather than requiring the device to maintain a separate upstream connection for every viewer or system.

Those subscribers might include:

A human operator controlling the device
A command center monitoring multiple devices
An AI model analyzing video or other data
A recording service preserving the session
A remote expert joining only when needed
A supervisor reviewing delayed or historical footage

This matters because embedded devices have limited power, processing capacity, and uplink bandwidth. Offloading distribution to the network can reduce the work required at the device.

Media and Related Data Can Share a Common Delivery Model

Robots and drones generate more than video. They may also produce audio, GPS coordinates, equipment status, telemetry, detection events, or other sensor data.

MOQ organizes content into addressable tracks, groups and objects. That creates the potential to transport related media and data through a common publish-and-subscribe model while preserving their logical relationships. An application could subscribe to the video and telemetry it needs without treating every data type as an unrelated workflow.

This does not mean MOQ replaces a device’s command-and-control system. Control signals may have different reliability, safety, and timing requirements. However, MOQ could provide a consistent distribution layer for the video, audio, sensor data, and machine-generated events that support operational decisions.

It Can Support Human and Machine Viewers

In many next-generation video systems, the first viewer may be an AI model rather than a person. A computer vision service could inspect a drone feed for smoke, structural defects, unauthorized activity, or damaged equipment, then publish detection data for human operators.

MOQ’s subscriber model could allow separate systems to request only the tracks or objects relevant to them. A browser might receive video and audio, while an AI pipeline consumes video plus metadata. A monitoring dashboard could subscribe to lower-bitrate previews from many devices and switch to a higher-quality track when an alert occurs.

This type of selective distribution can make large fleets easier to operate than architectures that send every feed and every data element through the same fixed path.

Live, Replay, and Recorded Workflows Could Converge

Remote operations don’t end when the live moment passes. Teams often need instant replay, time-shifted review, evidence retention, training footage, or post-event analysis.

Today, organizations may combine one protocol and infrastructure path for real-time operation with another for recording and on-demand playback. MOQ is being designed to support both real-time and non-real-time media delivery within a common architecture. For device operators, that could reduce the need to move between separate live and playback systems.

This is one reason MOQ may be especially valuable for applications that combine live and on-demand streaming. A team could monitor an active inspection, jump back to review a suspicious moment, and return to the live feed without changing to an entirely different delivery architecture.

Mobile Networks Make the Opportunity More Complicated

Robots and drones frequently operate on unstable wireless connections. They may move between 5G, LTE, Wi-Fi, satellite, or private networks while bandwidth, packet loss, and signal strength change from one moment to the next.

QUIC provides a useful foundation for changing network conditions, including multiplexed streams and modern congestion control. That does not mean MOQ automatically solves every mobility problem.

One important example is network bonding. SRT-based tools such as SRTLA can distribute traffic across multiple network links for added capacity and redundancy. A field device might combine connections from different cellular carriers so a weak or failed link does not immediately interrupt the stream.

MOQ will need practical answers for multipath connectivity, seamless handoffs, bandwidth adaptation, and rapid recovery if it is to support mission-critical mobile deployments. These capabilities may come from the protocol ecosystem, the underlying transport, device software, or surrounding network architecture rather than MOQ alone.

As discussed in our article on the emerging next-generation 5G streaming architecture, advanced mobile streaming will depend on cooperation between applications, transport systems, and network capabilities. The strongest device deployments will treat connectivity as part of the complete architecture rather than assuming one protocol can compensate for every network problem.

Security, Reliability, and Control Still Matter

Some of the most compelling robot and drone applications are also the least forgiving. Public safety, defense, industrial control, and remote healthcare cannot choose a transport protocol based on latency alone.

A production architecture may need:

Strong authentication and authorization for devices and viewers.
Encryption in transit and, where required, end-to-end protection.
Resilience when a relay, network path, or device connection fails.
Audit logs and recording policies.
Predictable behavior under congestion.
Fine-grained access to individual media and data tracks.
On-premises, private cloud, closed networks, or air-gapped deployment.
Clear separation between media delivery and safety-critical control.

MOQ’s security and media-format work is still evolving. For example, the IETF is developing a separate secure objects specification for authenticated encryption between publishers and subscribers, including scenarios in which relays should not be able to decrypt the content.

That work is promising, but an Internet-Draft is not the same as a mature, field-proven security profile. Organizations evaluating MOQ should test the complete system, not just the transport protocol.

What Must Happen Before MOQ Becomes the Missing Link

MOQ has a strong architectural fit for robots, drones, and embedded devices, but adoption will depend on more than a promising standard.

Device makers need efficient client implementations that can run within real limits on CPU, memory, battery life, and thermal performance. The industry also needs interoperable media formats, codec handling, hardware acceleration, and stable SDKs across embedded operating systems.
The ecosystem needs production-ready approaches to mobility. Network bonding, path changes, adaptation, and recovery must work under real field conditions, not only on stable test networks.
Operators need complete security and management capabilities. Provisioning thousands of devices, rotating credentials, enforcing permissions, monitoring performance, and updating software are essential parts of deployment.
MOQ implementations must prove interoperability as the IETF specifications continue to change. Teams evaluating the technology today should plan for revision rather than treating the current draft as a finished standard.

Red5 is already contributing to this ecosystem through the OpenMOQ Software Consortium and our work across MOQ transport, relay, and playback technologies. Developers can also evaluate MOQ through the Red5 Cloud MOQ beta or discuss self-hosted Red5 Pro deployment options.

Conclusion

MOQ’s opportunity in robotics is not simply that it can move video with low latency. Its greater potential is to connect one constrained device with many human and machine consumers while supporting live monitoring, AI analysis, recording, and playback through a shared architecture.

That could make MOQ a valuable foundation for drones, emergency-response robots, autonomous systems, industrial inspection tools, underwater vehicles, and other connected devices. Important gaps remain around mobility, security, embedded hardware support, and interoperability, so MOQ is not yet a universal answer.

Still, if the ecosystem solves those gaps, robots and drones may become some of the strongest examples of why real-time media needs a modern publish-and-subscribe protocol in the first place. For another perspective on how MOQ supports real-time video use cases, see 5 Reasons MOQ Streaming Is a Great Fit for Surveillance and Monitoring.

MOQ Hardware Support in 2026: Encoders, Players, and Technology Partners

Maria Artamonova — Wed, 09 Sep 2026 17:05:23 +0000

MOQ hardware support is becoming one of the most important topics in the evolution of real-time streaming. While much of the industry’s attention has focused on software implementations, a growing number of companies are also beginning to explore how MOQ fits into hardware-based workflows. In this article, we’ll look at the current state of MOQ hardware support in 2026, the vendors already participating in the ecosystem, and the technologies helping accelerate adoption.

What MOQ Hardware Support Really Means

Much of the discussion around MOQ has centered around software development and what needs to be in place to support the ecosystem. However, hardware support is also an important part of the equation. If MOQ is going to become a widely adopted transport protocol, it needs to work across the devices that capture, process, distribute, and play back video.

This does not necessarily mean manufacturers will need to redesign core encoding or decoding hardware. In many cases, supporting MOQ may primarily involve software updates that enable MOQ-compliant transport and playback workflows. That distinction is important because it can significantly reduce the cost and complexity of adopting MOQ.

That said, there is still substantial work to be done around implementing and optimizing MOQ across hardware platforms. The discussion becomes even broader when considering IoT devices, drones, robots, and other embedded systems, which introduce their own unique requirements and opportunities.

Early Movers in the MOQ Hardware Ecosystem

Although the MOQ ecosystem is still in its early stages, several hardware vendors have already begun developing and testing MOQ-enabled products. For the purposes of this discussion, it’s useful to divide the landscape into two categories: encoders and playback devices.

Encoders

Hardware support is essential if we want MOQ to become the default standard for broadcast and eventually replace SRT delivery.

We’re actively working with Osprey Video to enable live MOQ delivery, and testing compatibility with Red5’s MOQ relays and OpenMOQ’s MOQX implementations. More news on this coming soon.
It is also great to see Ateme, another OpenMOQ Consortium member, already demonstrating MOQ support in its encoder. In the “Oracle Video @ Edge: Showcasing Media over QUIC Partner Workflows at NAB” blog, Oracle shared the OVE MoQ Partner Integrations diagram, which features the Ateme live encoder.

Source: https://blogs.oracle.com/cloud-infrastructure/oracle-video-edge-media-over-quic-workflows-nab

We’re actively working with Videon to bring MOQ support to its encoders using the open-source MOQ5 library, which we’ll discuss in more detail later in this article.

As MOQ adoption expands, broadcast equipment vendors supporting standards such as ATSC 3.0 may also play an important role in bringing MOQ capabilities into traditional television workflows.

We are actively talking with other vendors, and this truly is just the beginning. I expect many more hardware vendors to step up, and this list is going to be huge by the time we discuss it again.

Players/Set-Top Boxes/Smart TVs

The player side has an equally important gap to fill.

We’re actively working with Amino on a MOQ-based player for its platform, opening the door to set-top boxes, media players, operator deployments, and Smart TV experiences. Many of the use cases we’ve previously discussed around WebRTC can also be delivered with MOQ, but with improved scalability and costs due to the ability to leverage CDN infrastructure.
Osprey Video also has Decoder devices, and we’re exploring opportunities to get MOQ playback working there as well.
Smart TVs remain one of the biggest opportunities. WebRTC never achieved broad adoption across television platforms, and therefore, there still is no viable real-time delivery mechanism for these devices. I’d like to see the industry avoid repeating that mistake. What I’d really like to see next is for Smart TV vendors such as Google TV, Samsung, ROKU, and LG to become more involved. Fortunately, YouTube is a member of the OpenMOQ Consortium, so I’m hopeful that the YouTube/Google folks can help convince the Google TV people to help lead the way.
Digital signage is another area where MOQ could have a significant impact. Beyond synchronized content delivery, it can support secure, real-time transactions such as digital signatures, identity verification, or ticket validation. Amino is one example, but I’d like to see more digital signage vendors embrace MOQ.

Native MOQ support across Smart TVs, set-top boxes, media players, and digital signage could dramatically expand where real-time streaming can be deployed. We’ve made great progress, but there’s still plenty of work ahead.

Open-Source Foundations for MOQ Hardware Support

On the software side, our team has developed MOQ5, an open-source C library with MOQ support for both ingest and egress. It provides an excellent foundation for implementing MOQ across a wide range of hardware platforms. You can learn more about this library in my latest blog post.

As part of the OpenMOQ Client Working Group, we’re actively building OBS, FFmpeg, and GStreamer implementations based on MOQ5. Those projects can then become the building blocks for hardware vendors looking to add native MOQ support.

MOQ5 also has bindings for Swift, and soon Kotlin, and Mobile devices on iOS and Android are two of the first target platforms. That said, I think mobile really belongs in its own category, and I probably should devote an entire post on that. So we will exclude it for today’s discussion.

We also see tremendous potential for robots, drones, and other embedded devices. I’ll probably also dedicate a future blog post to those use cases too.

Conclusion

MOQ hardware support is still in its early days, but the momentum is clearly building. Encoder manufacturers, player vendors, Smart TV platforms, and device makers all have an opportunity to help shape the future of real-time streaming while avoiding many of the adoption challenges that limited WebRTC’s reach outside the browser.

What excites me most is that we’re already seeing meaningful collaboration across the industry. OpenMOQ Consortium members, hardware vendors, CDN providers, and software developers are actively working together to make MOQ a practical reality.

As of July 2026, the list of companies exploring or implementing MOQ support remains relatively small, but it continues to grow. I’m particularly looking forward to seeing what emerges at IBC 2026 in Amsterdam this September. If the progress we’ve seen over the past year is any indication, the MOQ hardware ecosystem could look very different by the end of 2026.

How Video Packaging in Streaming Cuts Costs & Latencies in 2026

Maria Artamonova — Wed, 09 Sep 2026 16:36:28 +0000

Video packaging is becoming one of the most important factors in determining streaming costs, processing latency, monetization capabilities, scalability, and overall viewer experience. As ever more video services and applications surge across an expanding array of streaming formats, the mounting toll in operational inefficiencies calls for a cloud-anchored approach to packaging payloads that can cut costs and processing latencies in all scenarios.

Considering the gulf in packaging requirements between conventional and real-time streaming platforms, that’s a tall order. Modern packaging systems must coordinate transcoding, metadata, advertising, personalization, synchronization, and multi-protocol delivery while operating efficiently across cloud and on-premises infrastructure.

As demonstrated by the functional flexibility built into the Red5 Video Packager, it can be done. In this blog, you’ll learn what video packaging is, why its role is expanding across the streaming ecosystem, and how the Red5 Video Packager helps organizations reduce costs, lower latency, and support modern HTTP, WebRTC, and MOQ workflows from a unified architecture.

What is Video Packaging?

Video packaging is the process of preparing video, audio, metadata, captions, advertising markers, and other content components for delivery to viewers across different streaming protocols and devices. It organizes and formats streamed content into the structures required by technologies such as HLS, DASH, WebRTC, and MOQ while maintaining synchronization between all stream elements. Modern video packaging also supports functions such as dynamic advertising, personalization, DRM, metadata insertion, and low-latency delivery.

Why Video Packaging Is Becoming One of the Most Important Layers in Streaming

The streaming industry is evolving far beyond simple video delivery. Live streaming now represents the majority of the global video streaming market, while demand continues to grow for dynamic advertising, personalized viewing experiences, AI-powered enhancements, real-time interactivity, connected TV experiences, and ultra-low latency delivery. These requirements create significant processing, synchronization, and orchestration challenges that must be managed within the packaging layer. For a deeper look at the market trends driving these changes and the growing range of streaming use cases, download this white paper.

This demand is particularly visible in use cases like live sports, betting, auctions, live shopping, and interactive broadcasts, where timing, synchronization, personalization, and real-time latency all matter simultaneously. These are exactly the types of environments where live video packaging has become a critical operational requirement rather than a background infrastructure function.

Traditional packagers were designed for a very different world. Mostly HTTP streaming, static workflows, and non-latency-dependent delivery pipelines. They were never built for things like real-time metadata synchronization, AI-assisted recommendations, multilingual captioning, dynamic graphics insertion, SSAI, synchronized interactivity, or handling both live and VOD workflows together across multiple streaming modes.

What makes this even harder is that the industry is no longer dealing with a single delivery environment. Modern workflows increasingly need to support HTTP streaming, WebRTC, and soon MOQ at the same time. The fact is that not all devices support real-time protocols like WebRTC, and many use cases don’t require real-time. The same goes for the latest and greatest MOQ protocol. All of this is a big part of why we built the Red5 Video Packager differently.

What Makes the Red5 Video Packager Unique?

Most video packagers focus on formatting video for delivery. We designed the Red5 Video Packager as a cloud-native orchestration platform that helps organizations reduce costs, lower latency, and support both traditional and real-time streaming workflows from a single architecture. I’ll provide a brief overview of the key benefits below, but if you’d like a deeper look at the Red5 Video Packager, download the white paper.

1. One Architecture for HTTP, WebRTC, and MOQ

Instead of stacking isolated processing components together over time, we approached packaging as a cloud-native orchestration problem. The platform dynamically manages transcoding, packaging, compositing, metadata handling, SSAI, and stream synchronization across different streaming modes while minimizing latency and infrastructure costs.

We also designed our video packager as a node type in our XDN architecture that is fully managed by the Stream Manager. This means that our customers get all of the features from the other node types in the architecture like real-time transcoding (Transcoder), compositing (Mixer) and restream to Youtube or Facebook live with our custom plugins.

One thing I find particularly interesting is how much demand we are seeing around real-time ingest and processing workflows. Customers increasingly want to ingest RTMP, SRT, HLS, Zixi, MPEG-TS, RTSP, WebRTC, and MOQ streams into the same environment, then route them into live, VOD, DVR, AI, or monitoring workflows without rebuilding infrastructure around each protocol. We are now also introducing a new Video Extractor node in the next release that allows for real-time frame and audio extraction for passing to AI processes for real-time operational intelligence. The Stream Manager and its XDN architecture make all of this possible, allowing customers to configure video pipelines like a set of Lego pieces.

2. Built for Real-Time Latency

This is where ultra-low latency infrastructure changes the equation. Once you start operating below 250ms latency, many assumptions built into traditional packaging workflows stop working efficiently. You have to rethink synchronization, transcoding, ingest, and orchestration very differently. Even for companies that don’t need or want real-time delivery, the fact that our entire pipeline was built for real-time latency, means that we can shave off many many seconds before the traditional HTTP delivery goes out. This allows for less spoilers in sports broadcasts and much more.

We at Red5 have spent years building infrastructure capable of delivering streams at sub-250ms latency. That experience directly influenced the design of the Video Packager. Even when customers ultimately deliver content over HLS or DASH, many latency-inducing bottlenecks can be eliminated earlier in the workflow, reducing end-to-end delay and improving synchronization across streams, metadata, advertisements, and interactive experiences.

For live sports, auctions, betting, live shopping, and other time-sensitive applications, those seconds matter. Reducing processing delays before content reaches the delivery layer helps create more synchronized experiences and reduces the spoilers, timing mismatches, and user frustration that often accompany traditional streaming workflows.

3. Intelligent Resource Orchestration

Rather than treating packaging as a standalone function, our Video Packager works with Stream Manager to determine where processing should occur across cloud and on-premises environments. Packaging, transcoding, metadata processing, and stream synchronization can be distributed across infrastructure to minimize latency and improve resource utilization.

4. Lower Infrastructure Costs

Many streaming platforms default to expensive GPU resources for processing workloads. The Red5 Video Packager leverages technologies developed throughout the Red5 ecosystem to intelligently assign workloads to lower-cost CPU resources whenever possible, helping customers reduce cloud infrastructure costs without sacrificing performance.

5. Millisecond-Level Transcoding

Our Video Packager integrates with the Transcoder, which uses our MIRV architecture and Cauldron processing technology to generate adaptive bitrate renditions with extremely low processing overhead. This allows packaging workflows to operate with latency measured in milliseconds rather than adding seconds of delay to the delivery pipeline.

6. Multi-Cloud and Hybrid Deployment Flexibility

Customers can package and distribute streams across public cloud, private cloud, hybrid, and on-premises environments. This flexibility helps organizations avoid vendor lock-in while supporting a wide range of operational and compliance requirements.

Conclusion

As video services expand across a growing mix of traditional and real-time streaming formats, organizations face increasing pressure to control infrastructure costs, reduce processing latency, support monetization initiatives, and deliver increasingly sophisticated user experiences. Meeting these demands requires more than protocol support alone. It requires a packaging architecture that can efficiently coordinate transcoding, synchronization, metadata, advertising, and delivery workflows from a single platform.

As noted in the Red5 Video Packager white paper, organizations increasingly need a “cloud-anchored approach to packaging payloads that can cut costs and processing latencies” across multiple streaming formats. The Red5 Video Packager was built to address exactly that challenge, providing a flexible architecture that helps organizations streamline operations, lower costs, and support modern streaming workflows across HTTP, WebRTC, and MOQ environments.

5 Reasons MOQ Streaming Is a Great Fit for Surveillance and Monitoring

Maria Artamonova — Wed, 09 Sep 2026 16:10:07 +0000

Most conversations that I’m aware of around MOQ (Media over QUIC) focus on media and entertainment. Live sports, fan engagement, betting, and interactive broadcasts tend to dominate the headlines. However, MOQ streaming for surveillance and monitoring, drone & IP camera streaming, and public safety & defence are some of the most compelling applications for MOQ. Here are five reasons why.

1. Simpler connection management

When using WebRTC, one of the biggest operational challenges in large-scale real-time deployments is connection setup. WebRTC works extremely well for interactive communications, but it also comes with ICE negotiation and other complexities. Many surveillance workflows are much simpler. Cameras publish streams and operators subscribe to them. MOQ has the potential to simplify that architecture considerably.

2. Built for scale without sacrificing real-time performance

One of the biggest advantages of MOQ streaming for surveillance and monitoring is its ability to scale across hundreds or thousands of video sources without sacrificing real-time performance. Surveillance and monitoring deployments often involve hundreds or thousands of cameras distributed across cities, transportation networks, industrial sites, and public safety systems. These systems usually use RTSP- or other TCP-based video delivery protocols. MOQ combines real-time latency with the scalability traditionally associated with CDN architectures. By leveraging QUIC instead of TCP, it avoids issues like head-of-line blocking that can slow delivery in congested networks. The result is a more efficient way to distribute live video at scale while maintaining the responsiveness that operational environments require.

3. Legacy camera compatibility and modern streaming workflows

Organizations do not need to replace existing camera infrastructure (usually RTSP– or RTMP-based) to benefit from MOQ’s advantages. Most deployments already have significant investments in legacy cameras and video systems. With Red5, organizations can continue using those existing video sources while delivering streams through modern protocols and workflows. That makes it possible to adopt innovations like MOQ, AI-powered analytics, and real-time distribution without starting from scratch or replacing hardware that still works.

4. Easier sharing across departments and agencies

One challenge I see repeatedly is that video systems often operate in silos. Transportation departments, law enforcement agencies, emergency responders, and operations centers frequently use separate systems that do not easily communicate with one another. Making live video accessible across multiple departments can dramatically improve situational awareness and coordination.

For example, one of our customers, Caltrans District 7, uses a Red5-powered traffic monitoring solution that provides a unified interface for viewing and sharing live and recorded roadway video across agencies, including the California Highway Patrol. This cross-agency visibility has improved decision-making during fires, disasters, and major incidents, and has even helped solve crimes, including a recent highway shooting case in which investigators identified the suspect using live and recorded video footage.

5. Better support for AI-powered monitoring

The future of surveillance is not more people staring at more screens. It is AI helping operators identify what matters. Organizations are increasingly using AI and vision-language models to detect accidents, identify traffic congestion, monitor critical infrastructure, detect wildfires, and surface other events that require immediate attention. Learn more about it from our previous blog “AI Detection Is Set to Transform Live Streaming“.

The faster video can move through the system, the faster those insights can be generated and acted upon. As AI becomes increasingly important for operational awareness, MOQ streaming for surveillance and monitoring can help deliver video data to analytics systems with minimal delay.

How Can You Try MOQ Streaming

Depending on your requirements for control and customization, you can take advantage of MOQ with either of our real-time streaming products:

1. Red5 Cloud (fully managed PaaS): in partnership with global CDN operator CacheFly, we’ve launched one of the first end-to-end production-ready MOQ streaming solutions that operates at global scale. Deploy real-time streaming without managing infrastructure, scaling, monitoring, or performance optimization. Join our limited beta.

2. Red5 Pro (self-hosted server software): The MOQ plugin integrates a full MoQ Transport relay server into Red5 Pro, adding QUIC-based streaming alongside the existing protocol stack. Deploy it on-premises, in closed networks and air-gapped environments, in public or private clouds, or in hybrid deployments. Use the CDN of your choice. Reach out to discuss your case.

Conclusion

MOQ streaming for surveillance and monitoring offers a practical path to lower latency, greater scalability, and more efficient video distribution. It also allows organizations to modernize their streaming workflows while continuing to use existing camera infrastructure and preparing for AI-driven operations.

As more organizations look for scalable ways to combine real-time video, AI analysis, and cross-agency collaboration, I think surveillance and monitoring are use cases worth watching closely. What do you think?