DEV Community: Maria Artamonova

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

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

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

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

H.266 vs. AV1: The Short Answer

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

What Developers Are Using in 2026

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

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

What Are H.266/VVC and AV1?

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

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

H.266 vs. AV1 Comparison Table

Compression Efficiency and Video Quality

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

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

Encoding Complexity and Hardware Support

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

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

Browser and Device Compatibility

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

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

Licensing and Operational Cost

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

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

H.266 vs. AV1 for Live Streaming

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

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

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

Which Codec Should You Choose?

Choose AV1 when:

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

Evaluate H.266 when:

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

How to Test H.266 vs. AV1

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

FAQs

Is H.266 better than AV1?

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

Which codec is better for live streaming?

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

Does H.266 reduce streaming latency?

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

Conclusion

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

The MOQ Shot Heard Around the World After IBC 2026

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

Introduction

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

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

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

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

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

Commercializing MOQ

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

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

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

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

Under the Hood at IBC

A First in Demonstrated MOQ Streaming Interactivity

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

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

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

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

Hyperscalers’ MOQ Strategies

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

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

Oracle

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

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

AWS

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

Akamai

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

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

The Red5 MOQ Commercialization Timeframe

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

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

Player and C Library Templates

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

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

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

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

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

Exclusive Software Components

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

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

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

The Importance of Networking Knowhow

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

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

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

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

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

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

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

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

Conclusion

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

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

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

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

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

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

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

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

What Is 5G Live Streaming?

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

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

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

How 5G Live Streaming Works from Camera to Viewer

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

1. Capture and encoding

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

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

2. 5G uplink and contribution

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

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

3. Edge or cloud processing

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

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

4. Stream distribution

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

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

5. Playback and interaction

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

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

The Benefits of 5G Live Streaming

More freedom at the point of capture

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

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

Greater support for remote production

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

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

A shorter path to edge applications

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

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

Better support for high-value interactive experiences

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

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

New options for private production networks

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

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

Why 5G Does Not Automatically Guarantee a Reliable Stream

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

Coverage and capacity are not the same

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

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

Uplink performance deserves special attention

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

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

Low network latency is not glass-to-glass latency

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

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

Network slicing and quality APIs are still developing commercially

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

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

Security must cover the full workflow

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

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

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

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

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

5G Live Streaming Use Cases

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

How Red5 Completes the 5G Live Streaming Workflow

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

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

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

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

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

A Practical 5G Live Streaming Checklist

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

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

Conclusion

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

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

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

RTMP vs SRT: Which Ingest Protocol Should You Use?

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

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

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

RTMP vs SRT at a Glance

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

What Is RTMP?

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

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

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

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

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

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

What Is SRT?

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

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

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

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

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

Key Differences Between RTMP and SRT

Reliability on Unpredictable Networks

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

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

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

Latency

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

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

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

Security

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

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

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

Codec and Payload Support

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

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

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

Encoder and Platform Compatibility

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

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

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

When Should You Use RTMP or RTMPS?

Choose RTMP or RTMPS when:

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

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

When Should You Use SRT?

Choose SRT when:

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

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

Can You Use RTMP and SRT Together?

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

A mixed workflow can look like this:

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

Using RTMP and SRT With Red5

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

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

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

FAQs

Is SRT better than RTMP?

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

Is SRT always lower latency than RTMP?

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

Does SRT include encryption?

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

Can OBS Studio stream with SRT?

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

Conclusion

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

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

Escalating Battle against AI Deepfakes Mandates Smart Streaming Decisions

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

Introduction

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

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

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

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

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

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

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

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

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

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

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

The Deepfake and Deterrence Landscape

The Ascending Assault Vector

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

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

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

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

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

Deepfake Deterrence Moves to the Global Front Burner

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

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

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

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

C2PA Provenance Validation

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

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

Pluses & Minuses in C2PA Support

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

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

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

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

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

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

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

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

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

The Breakthrough in Live Stream Provenance Validation

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

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

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

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

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

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

Vulnerabilities to Relying on C2PA

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

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

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

Uncertainties in the Detection Battle against Deepfakes

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

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

The Hacker Pushback

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

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

Misleading Performance Metrics & Other Issues

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

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

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

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

Preparing for What Comes Next

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

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

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

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

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

Leveraging XDN Edge Intelligence

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

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

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

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

Support for Real-Time C2PA Validation

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

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

Making Deepfake Detection Effective in Live Streaming

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

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

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

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

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

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

Expediting Integration of Deepfake Detection Tools

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

Conclusion

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

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

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.