• H.266 vs. AV1: The Short Answer

• What Developers Are Using in 2026

• What Are H.266/VVC and AV1?

• H.266 vs. AV1 Comparison Table

• Compression Efficiency and Video Quality

• Encoding Complexity and Hardware Support

• Browser and Device Compatibility

• Licensing and Operational Cost

• H.266 vs. AV1 for Live Streaming

• Which Codec Should You Choose?

  • Choose AV1 when:

  • Evaluate H.266 when:

• How to Test H.266 vs. AV1

• FAQs

  • 
    

• Conclusion

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

1. Select representative content, including motion, fine detail, graphics, and low-light scenes.

2. Encode both codecs at matched quality targets and equivalent resolution, frame rate, and color format.

3. Measure bitrate, visual quality, encoding delay, CPU or GPU use, memory, and cost.

4. Test decoding on the actual browser, phone, television, and managed-device mix.

5. 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 post H.266 vs AV1 for Live Streaming: What Codec to Choose appeared first on Red5.

• Introduction

• Commercializing MOQ

• Under the Hood at IBC

  • A First in Demonstrated MOQ Streaming Interactivity

  • Hyperscalers’ MOQ Strategies

    • Oracle

    • AWS

    • Akamai

• The Red5 MOQ Commercialization Timeframe

  • Player and C Library Templates

  • Exclusive Software Components

  • The Importance of Networking Knowhow

• Conclusion

IBC 2026 Confirms M&E Transition to Next-Gen Streaming Is Real

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 Meetings 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 TypeScript 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 TrueTime toolsets. Along with the aforementioned TrueTime Meetings, these include TrueTime MultiView

, TrueTime WatchParty, TrueTime Datasync

, and TrueTime Studio. 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.

The post The MOQ Shot Heard Around the World After IBC 2026 appeared first on Red5.

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

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

1. Define acceptable end-to-end latency for each user action, not just for video playback.

2. Document contribution bitrate, rendition ladder, audio bitrate, overhead, and concurrency assumptions.

3. Measure upload and download throughput and application goodput from representative networks and regions.

4. Measure idle and loaded RTT, jitter, loss, and glass-to-glass delay.

5. Choose protocol, recovery, and buffer settings that match the application’s tolerance for delay and artifacts.

6. Place media processing and delivery nodes close to publishers and viewers.

7. Expose session telemetry so support teams can separate client, access-network, route, server, and player problems.

8. Load-test the complete workflow, including transcoding, relays, signaling, and egress.

9. 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.

• What’s New in Red5 Pro v16.1.0?

  • New Features

  • Improvements

  • Bug Fixes

• Conclusion

Let’s take a look at the latest Red5 Pro release following our previous blog about Red5 Pro v16.0.0. Red5 Pro v16.1.0 introduces EZDRM integration, ONVIF camera support, and an object detection plugin, along with Stream Manager improvements and bug fixes that strengthen real-time streaming workflows.

Need a custom Red5 Pro feature developed or want to prioritize a development request? We’re known for our flexibility. Contact us to discuss your needs.

What’s New in Red5 Pro v16.1.0?

Here is what you need to know about the Red5 Pro v16.1.0 update announced on September 14, 2026.

New Features

• EZDRM integration. Red5 Pro now integrates with EZDRM to help teams protect premium live video without building and maintaining a separate custom DRM workflow. This makes secure delivery easier to implement and manage while helping content owners safeguard distribution rights and revenue.

• ONVIF camera support. You can connect, stream from, and control supported ONVIF-compatible IP, traffic, and PTZ cameras within your workflows. This supports real-time video feeds and responsive camera management for intelligent transportation and emergency monitoring systems while reducing the need for custom camera integrations.

• Object detection plugin for the analyzer node via frame extraction. With real-time frame extraction and AI-powered object detection, extractor nodes send video frames to an Analyzer GPU node running the Red5 Analyzer SDK’s new object detection plugin. The detection results can then be routed over WebRTC data channels to subscribers or other destinations, enabling applications such as automated monitoring, spatial analytics, and interactive computer vision workflows without adding analysis-related latency to the primary video path.

Improvements

• Stream Manager now houses all secrets in as-admin.

• Kafka for Stream Manager updated to 4.3.1.

Bug Fixes

• The server no longer generates excessive logs when recording WHIP streams with data channel data.

• Fixed a memory leak during WHIP publishing when the video source stalls.

• Stream recording now honors screen orientation.

• Basic and digest authentication now operate properly when restreaming from IP cameras.

Conclusion

Red5 Pro v16.1.0 improves usability and reliability for real-time streaming workflows. With EZDRM integration, ONVIF camera support, an object detection plugin, Stream Manager improvements, and targeted bug fixes, this release expands secure, intelligent, and manageable streaming options for developers, startups, and enterprises.

The post What’s New In Red5 Pro v16.1.0? EZDRM Integration, ONVIF Camera Support, Object Detection Plugin, And More! appeared first on Red5.

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.

• Introduction

• Accelerating Progress toward MOQ Adoption

• Best-of-Breed Content Protection with Converged Packaging

• A Major Enhancement to Multi-DRM Streaming

• Integrated Support for C2PA Provenance Verification

• Keeping Pace with Evolving Security Requirements

• Conclusion

Consolidated Packaging Includes C2PA Service Option & Much Else

Introduction

Red5, in an alliance with EZDRM, has taken an important step toward normalization of MOQ (Media over QUIC) as the standardized gateway to next-generation streaming with unified packaging of best-of-breed multi-DRM protection for use in all streaming scenarios via the Red5 Video Packager.

EZDRM’s world-class DRM-as-a-Service platform supporting multi-DRM, anti-fake provenance validation and other security-related advances is now fully integrated with our Video Packager. That means superior streaming revenue security can be automatically activated when needed to secure any payload streamed live or on demand over any of the leading streaming infrastructures, including those supporting the new MOQ Transport standard developed by the Internet Engineering Task Force (IETF).

This makes it easy for customers to activate a market-leading approach to protecting content operating over conventional CDNs. And, in a move that allows our customers to avoid the challenges that go with making DRM usage compatible with MOQ, we’re making EZDRM the default protection mode for Red5 Cloud customers who operate over the global MOQ CDN infrastructure we’ve built in partnership with CacheFly or any others we may bring to market in the future.

Security, including standardized DRM is, of course, critical to making MOQ a viable platform for streaming premium content whether live or on demand. In nearly all cases, premium content targeted to consumer audiences can’t be licensed for distribution without the policy-enforcement mechanisms embodied in the leading DRM systems.

A multi-DRM system like EZDRM’s is packaged with premium content to employ whichever DRM system works with internet-connected devices to execute policy controls that determine whether users are authorized to receive the decryption keys that unlock access. And DRM is also widely used to protect A/V payloads distributed in restricted enterprise and institutional use cases.

Accelerating Progress toward MOQ Adoption

Conversion to the real-time and other streaming benefits provided by MOQ, which is not directly compatible with conventional HTTP-based streaming, poses challenges at both the transport and media layers of streaming architecture. But much has already been accomplished to make the transition as smooth as possible.

As described here, the IETF, which is close to finalizing the MOQ Transport specifications, has done a remarkable job using open-source components that minimize the costs and hassles of infrastructure transformation to create a much more versatile streaming environment with latencies tunable from real-time to multi-second speeds and independently manageable application tracks encapsulated within each payload. At the media layer, IETF is also formulating specifications for media layer formatting, including the MOQ Streaming Format (MSF) and the companion CMAF-optimized CMSF, while encouraging others to do likewise.

At Red5 we’ve worked with CacheFly to achieve MOQ compatibility on its CDN with support for multi-transport protocol ingestion into and egress from MOQ relays created through use of our Experience Delivery Network (XDN) Architecture to orchestrate cloud resources under CacheFly’s control. At the same time, we’ve taken major steps with the Red5 Video Packager and our Playa client player framework to streamline operations at the MOQ media layer.

As explained in this white paper, our packager achieves the essential goal of reducing the costs and complexities of streaming content in a multi-transport platform environment by enabling not only the aggregation of payload elements and functions but also efficient use of processing resources across all the major streaming infrastructures as customers move from one streaming mode to the next. And, as described here, the Playa player has been endorsed by the OpenMOQ Software Consortium as a template for building MOQ players suited to playback involving any use case supported by the IETF’s or other MOQ streaming formats. We, of course, have built Playa into our Red5 SDK and associated MOQ player and publishing capabilities.

Best-of-Breed Content Protection with Converged Packaging

Now customers can benefit from this single-silo unification of stream packaging knowing they can implement the EZDRM platform with MOQ as effortlessly as they can in any other streaming environment. Critically, as the only next-gen DRM platform supplier to have joined the OpenMOQ Consortium, EZDRM has left no doubt that it can measure up to its ironclad performance standards in the MOQ domain.

Our integration with Red5 and the things we demonstrated at the NAB Show prove our multi-DRM, C2PA and other advanced content security solutions work with MOQ.”

– David Eisenbacher, CEO & Co-Founder, EZDRM

In fact, our partnership is a natural outgrowth of our interactions through the consortium. As a founding member, Red5 has had a front-row seat witnessing the validations of reliability and scope of security EZDRM brings to MOQ streaming, which came to light at the recent NAB Show.

There, as reported by the OpenMOQ Consortium, EZDRM collaborated with Qualabs and Ateme to demonstrate the first implementation of content protection built directly into MOQ with provenance verification through the Content Credentials formulated in compliance with the C2PA standard developed by the Coalition for Content Provenance and Authenticity. The end-to-end live streaming workflow leveraged EZDRM’s multi-DRM support with MOQ Relays that were also equipped to sign C2PA Content Credentials into each segment for delivery of live provenance validation to all recipients.

This was a significant achievement requiring modifications across three open-source projects. These included adapting processing in MOQ Relays to sign content in real time with the arrival of each stream segment; extension of C2PA Rust SDKs (C2PA-RS) to handle live CMAF streams, and tuning the C2PA JavaScript repository (C2PA-js) to ensure player-side verifications synchronize with playback.

As we reported in this blog, Red5’s MOQ-related demos were also part of the industry-wide display of support for the new streaming standard that unfolded at NAB 2026. Now with MOQ operations underway globally on our own and many other CDN and vendor streaming platforms, the availability of a fully baked MOQ-optimized content protection system as the default option on the managed Red5 Cloud MOQ streaming service is a big inducement to market adoption of the real-time and other next-gen streaming capabilities that can be achieved with MOQ.

We are glad to be ahead of the adoption curve for MOQ services. We believe that we’ve proven our security delivered over MOQ infrastructure works seamlessly in M&E customers’ workflows. There’s now an opportunity for the rest of the industry to expand on these foundations and create a broader commercial streaming environment.. Part of that is to have people building out more elements of the MOQ infrastructure.”

– Olga Kornienko, COO & Co-Founder, EZDRM

EZDRM’s cloud-based Universal Complete multi-DRM service is widely recognized for supporting simple activation of robust protection across virtually all devices with dynamically scalable, multi-cloud redundancy. Along with the Widevine, FairPlay and PlayReady DRM systems that dominate streaming in the U.S. and many other places, Universal Complete extends comprehensive protection globally to devices linked to the Huawei WisePlay DRM.

Adding to the versatility, EZDRM works with customers to tailor protection in B2B and other scenarios where all devices work on a single DRM system, in which case there’s no need to implement the full Universal Complete service.

When it comes to mass market premium content streaming, Universal Complete embeds all major DRM systems in a single origin file while allowing flexible license server configurations in multi-regional deployments with support for consistent low-latency delivery enabled by resistance to packet loss and network variability in all locations. The multi-DRM system is compatible with packaging as formulated by individual streaming formats and works with unified packaging enabled by the Common Media Application Format (CMAF) whenever possible, which along with maximizing efficient use of DRM protection creates a fallback to conventional streaming of CMAF-packaged payloads in the event of MOQ Transport failures when the MOQ Streaming Format or other CMAF-optimized MOQ streaming modes are in use.

In all cases involving use of its technology, EZDRM provides support for quality control through real-time monitoring, detailed logging of license transactions and alerting for anomalies or failures. Commitments to service resilience are documented in SLAs with uptime guarantees and other performance benchmarks matched to cloud operators’ and other ecosystem parameters.

A Major Enhancement to Multi-DRM Streaming

A key advantage of the EZDRM approach to content protection entails the decoupling of DRM robustness rules like output protection and business-related DRM consumption policies from the mechanics of the stream encryption process. One outgrowth of this architecture pertains to the dynamic key generation policies used with live-streamed premium content.

While the basic Universal Complete package supports the universal rotational key refreshments delivered at regular intervals to all session participants in all locations, EZDRM has gone much further with an optional key management service that overcomes the inadequacies of this traditional approach. In those scenarios the same refreshment keys are often sent to all live session viewers, increasing vulnerability to pirates’ rapid-fire DRM scraping techniques while incurring issues related to license regeneration overhead that are made worse in massively viewed event streaming involving high-volume “license storms” and the aggregated impact of glitches at the device level.

In contrast, EZDRM’s optional Precision Envelope Management (PEM) service can be seamlessly activated with Universal Complete or on a standalone basis to support a much more distributed approach to key rotation and live content protection. While DRM remains the centralized authority for entitlements and core cryptographic protection mechanisms, PEM provides a complementary enhancement to protection by adding a cryptographic layer that employs granular key management and rapid key rotation targeted in time and by location from CDN edge nodes to locally engaged devices, which greatly reduces stream vulnerability to scraping attacks and illegal license sharing.

Integrated Support for C2PA Provenance Verification

Another service option that can be seamlessly activated with EZDRM protection in the Red5 Video Packager or any others used with MOQ and other streaming formats entails the previously mentioned support for C2PA. The standard has gained broad acceptance as a common format creators and publishers can use to embed metadata and cryptographic proofs of provenance legitimacy in digital media with certified Content Credentials consumers can rely on to know they’re not receiving fakes.

This is especially important to news broadcasters eager to counter the rising tide of AI-doctored versions of their content permeating the internet, but with fakes spreading to all corners of the media universe, the need for CP2A is intensifying well beyond news feeds. The European Union’s law enforcement agency Europol issued a report in 2024 that predicted up to 90% of online content would be generated synthetically. As for the news sector, a study released by Reuter’s Institute for the Study of Journalism in 2025 found that 74% of adults surveyed worldwide said they were encountering misinformation in news feeds at least once a week.

As a member of the Coalition for Content Provenance and Authenticity, EZDRM has taken a leading role in the drive to establish a common approach to validating content provenance. In February, the EZDRM Video Signature Service (VSR) became the first Level 2 conformance generator to be verified by the organization. And, as noted above, the EZDRM collaboration with Qualabs and Ateme at NAB Show 2026 produced the first implementation of content protection built directly into MOQ with C2PA-based provenance verification.

EZDRM’s support for the Level-2 C2PA certification entails independently validated signing of credentials with secure private key-management controls that go further than the more basic developer-managed trust models used at Level 1 to ensure content generator identities are authentic. C2PA-authenticated content can be labeled with Content Credential “pins” to make the validation visible to consumers or content generators can leave it to professionals in the distribution chain to check for invisibly embedded C2PA metadata through their browsers or other means.

Adding to the utility of EZDRM’s C2PA support, the VSR service is complemented by availability of the EZDRM Provenance Security Vault (PSV) and the low-latency Provenance Repository System (PRS). The PSV aids providers in high-volume C2PA use cases by ensuring the provenance metadata is securely stored in a separate, trusted location outside the immediate media file or container. The PRS seamlessly integrates with existing streaming workflows to facilitate content traceability and accountability in sports, news and other large-scale distributions.

All of these capabilities are available with EZDRM implementations through Red5’s universal Video Packager. This sets the course both companies will be following as C2PA gains traction and additional tools focused on thwarting the deep-fake threat enter the market.

Keeping Pace with Evolving Security Requirements

There’s a long way to go in that regard, even with wider adoption of C2PA. While C2PA provides a standardized way to establish provenance authenticity, there are vulnerabilities sophisticated perpetrators of deep-fake agendas are sure to probe, as spelled out 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. Drilling down to specific instances, one new report names a remote code execution vulnerability tied to Adobe’s C2PA-based Content Authenticity Initiative.

These challenges underscore the importance of due diligence when it comes to choosing DRM suppliers. Red5 customers can be sure the strong start toward combatting deep fakes that’s now attainable through access to the EZDRM platform will continue at the leading edge of security as C2PA and other experts add new protections for adoption into the VSR service.

And they can also be confident they’ll have recourse to guidance in taking care of other security concerns as embodied in the multiple layers of what EZDRM calls the Revenue Security Prism. It’s a label that’s meant to emphasize that multi-DRM protection is a foundational security layer working with many other mechanisms that go into fully securing high-value online content.

These include C2PA provenance integrity, localized key rotations and session tokenization tying playback authorization to a specific session or device as directly supported by EZDRM as well as third-party solutions operating in the other Prism layers. That side of the ledger includes forensic watermarking; geofencing, which reinforces geographic limitations on content consumption, and VPN detection that’s aimed at detecting and defeating malign efforts to hide user locations.

Customers seeking clarity on what they need and where to find the best solutions can benefit from EZDRM’s hands-on expertise in all these areas. In applications involving third-party solutions, that know-how stems in part from work with best-of-breed partners whose platforms are often deployed in tandem with the sophisticated DRM solutions supplied by EZDRM.

Conclusion

The Red5-EZDRM alliance has set a new benchmark defining the efficiency, flexibility and range of capabilities creators, publishers and service providers can expect in pursuit of optimum content security. Through the integration of EZDRM’s multifaceted cloud-based DRM-as-a-Service core with Red5’s multi-protocol Video Packager best-of-breed content security can be employed from a single portal with live and on-demand streaming sessions delivered via HLS, Low-Latency HLS, MPEG-DASH, Low-Latency DASH, or MOQ.

As the first multi-DRM service to offer integrated support for C2PA provenance verification in the MOQ streaming environment, the EZDRM platform is now the default protection solution for Red5 Cloud customers executing MOQ streaming over the next-gen global CDN created through Red5’s partnership with CacheFly. EZDRM’s C2PA-compliant Video Signature Service is also available along with other EZDRM advancements for use with the Red5 Video Packager in all other streaming scenarios.

Those extensions include rapid key rotation and geo-targeting offered through the Precision Envelope Management service with optional backing for efficient large-scale PEM applications through the EZDRM Provenance Security Vault and the low-latency Provenance Repository System. These are now available for packaging with all the traditional streaming modes and will soon be available for use with MOQ streaming on the Red5 Cloud service.

In very short order, MOQ has emerged as a force to be reckoned with across the video streaming ecosystem. Now everyone exploring MOQ as a next-gen streaming solution that reduces complexities and costs with multi-latency flexibility and unlimited use case granularity can move toward commercial adoption knowing the best in content protection will be activated automatically whenever they need it.

To learn more about the Red5-EZDRM partnership with an eye on what comes next, contact us any time. Use this link to sign up for beta testing MOQ as we prepare for commercial rollout.

The post Red5 & EZDRM Team to Streamline Delivery of Content Security Across MOQ & All Other Streaming Protocols appeared first on Red5.

• What Is 5G Live Streaming?

• How 5G Live Streaming Works from Camera to Viewer

  • 1. Capture and encoding

  • 2. 5G uplink and contribution

  • 3. Edge or cloud processing

  • 4. Stream distribution

  • 5. Playback and interaction

• The Benefits of 5G Live Streaming

  • More freedom at the point of capture

  • Greater support for remote production

  • A shorter path to edge applications

  • Better support for high-value interactive experiences

  • New options for private production networks

• Why 5G Does Not Automatically Guarantee a Reliable Stream

  • Coverage and capacity are not the same

  • Uplink performance deserves special attention

  • Low network latency is not glass-to-glass latency

  • Network slicing and quality APIs are still developing commercially

  • Security must cover the full workflow

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

• 5G Live Streaming Use Cases

• How Red5 Completes the 5G Live Streaming Workflow

• A Practical 5G Live Streaming Checklist

• Conclusion

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.

The post 5G Live Streaming: Benefits, Challenges, and How It Works appeared first on Red5.

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.

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.

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.

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

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

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

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

The same pattern appears in many industries:

• Public safety robots can send video to operators, incident commanders, and remote specialists.

• Industrial inspection drones can share feeds with engineers, asset owners, and AI defect-detection systems.

• Autonomous or remotely operated vehicles can deliver video and sensor data to control centers and fleet-management platforms.

• Agricultural drones can stream crop imagery to operators and computer vision systems.

• Underwater vehicles can connect offshore crews with experts located anywhere in the world.

• Broadcast drones can supply live production feeds while creating recordings for replays and highlights.

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

Where Current Streaming Protocols Fit

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

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

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

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

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

What Makes MOQ Interesting for Embedded Devices

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

One Published Feed Can Serve Many Subscribers

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

Those subscribers might include:

• A human operator controlling the device

• A command center monitoring multiple devices

• An AI model analyzing video or other data

• A recording service preserving the session

• A remote expert joining only when needed

• A supervisor reviewing delayed or historical footage

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

Media and Related Data Can Share a Common Delivery Model

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

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

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

It Can Support Human and Machine Viewers

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

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

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

Live, Replay, and Recorded Workflows Could Converge

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

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

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

Mobile Networks Make the Opportunity More Complicated

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

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

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

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

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

Security, Reliability, and Control Still Matter

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

A production architecture may need:

• Strong authentication and authorization for devices and viewers.

• Encryption in transit and, where required, end-to-end protection.

• Resilience when a relay, network path, or device connection fails.

• Audit logs and recording policies.

• Predictable behavior under congestion.

• Fine-grained access to individual media and data tracks.

• On-premises, private cloud, closed networks, or air-gapped deployment.

• Clear separation between media delivery and safety-critical control.

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

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

What Must Happen Before MOQ Becomes the Missing Link

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

1. Device makers need efficient client implementations that can run within real limits on CPU, memory, battery life, and thermal performance. The industry also needs interoperable media formats, codec handling, hardware acceleration, and stable SDKs across embedded operating systems.

2. The ecosystem needs production-ready approaches to mobility. Network bonding, path changes, adaptation, and recovery must work under real field conditions, not only on stable test networks.

3. Operators need complete security and management capabilities. Provisioning thousands of devices, rotating credentials, enforcing permissions, monitoring performance, and updating software are essential parts of deployment.

4. MOQ implementations must prove interoperability as the IETF specifications continue to change. Teams evaluating the technology today should plan for revision rather than treating the current draft as a finished standard.

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

Conclusion

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

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

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

What MOQ Hardware Support Really Means

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

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

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

Early Movers in the MOQ Hardware Ecosystem

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

Encoders

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

• We’re actively working with Osprey Video to enable live MOQ delivery, and testing compatibility with Red5’s MOQ relays and OpenMOQ’s MOQX implementations. More news on this coming soon.

• It is also great to see Ateme, another OpenMOQ Consortium member, already demonstrating MOQ support in its encoder. In the “Oracle Video @ Edge: Showcasing Media over QUIC Partner Workflows at NAB” blog, Oracle shared the OVE MoQ Partner Integrations diagram, which features the Ateme live encoder.

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

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

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

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

Players/Set-Top Boxes/Smart TVs

The player side has an equally important gap to fill.

• We’re actively working with Amino on a MOQ-based player for its platform, opening the door to set-top boxes, media players, operator deployments, and Smart TV experiences. Many of the use cases we’ve previously discussed around WebRTC can also be delivered with MOQ, but with improved scalability and costs due to the ability to leverage CDN infrastructure.

• Osprey Video also has Decoder devices, and we’re exploring opportunities to get MOQ playback working there as well.

• Smart TVs remain one of the biggest opportunities. WebRTC never achieved broad adoption across television platforms, and therefore, there still is no viable real-time delivery mechanism for these devices. I’d like to see the industry avoid repeating that mistake. What I’d really like to see next is for Smart TV vendors such as Google TV, Samsung, ROKU, and LG to become more involved. Fortunately, YouTube is a member of the OpenMOQ Consortium, so I’m hopeful that the YouTube/Google folks can help convince the Google TV people to help lead the way.

• Digital signage is another area where MOQ could have a significant impact. Beyond synchronized content delivery, it can support secure, real-time transactions such as digital signatures, identity verification, or ticket validation. Amino is one example, but I’d like to see more digital signage vendors embrace MOQ.

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

Open-Source Foundations for MOQ Hardware Support

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

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

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

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

Conclusion

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

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

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

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

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

What is Video Packaging?

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

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

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

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

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

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

What Makes the Red5 Video Packager Unique?

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

1. One Architecture for HTTP, WebRTC, and MOQ

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

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

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

2. Built for Real-Time Latency

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

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

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

3. Intelligent Resource Orchestration

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

4. Lower Infrastructure Costs

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

5. Millisecond-Level Transcoding

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

6. Multi-Cloud and Hybrid Deployment Flexibility

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

Conclusion

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

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

1. Simpler connection management

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

2. Built for scale without sacrificing real-time performance

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

3. Legacy camera compatibility and modern streaming workflows

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

4. Easier sharing across departments and agencies

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

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

5. Better support for AI-powered monitoring

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

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

How Can You Try MOQ Streaming

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

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

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

Conclusion

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

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

• RTMP vs SRT at a Glance

• What Is RTMP?

• What Is SRT?

• Key Differences Between RTMP and SRT

  • Reliability on Unpredictable Networks

  • Latency

  • Security

  • Codec and Payload Support

  • Encoder and Platform Compatibility

• When Should You Use RTMP or RTMPS?

• When Should You Use SRT?

• Can You Use RTMP and SRT Together?

• Using RTMP and SRT With Red5

• FAQs

  • 
    

• Conclusion

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.

The post RTMP vs SRT: Which Ingest Protocol Should You Use? appeared first on Red5.

• Introduction

• The Deepfake and Deterrence Landscape

  • The Ascending Assault Vector

• Deepfake Deterrence Moves to the Global Front Burner

  • C2PA Provenance Validation

  • Pluses & Minuses in C2PA Support

• The Breakthrough in Live Stream Provenance Validation

  • Vulnerabilities to Relying on C2PA

• Uncertainties in the Detection Battle against Deepfakes

  • The Hacker Pushback

  • Misleading Performance Metrics & Other Issues

• Preparing for What Comes Next

  • Leveraging XDN Edge Intelligence

  • Support for Real-Time C2PA Validation

  • Making Deepfake Detection Effective in Live Streaming

  • Expediting Integration of Deepfake Detection Tools

• Conclusion

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.

The post Escalating Battle against AI Deepfakes Mandates Smart Streaming Decisions appeared first on Red5.

This guide to MOQ demos at IBC 2026 gives streaming teams a practical way to compare MOQ (Media over QUIC) implementations beyond protocol discussions. The publicly announced demos span interactive video delivery, real-time playback, and DRM-protected workflows, making the show a useful place to ask how each architecture handles packaging, security, relay, playback, and fallback delivery.

Confirmed MOQ Streaming Demos at IBC 2026

Red5 + CacheFly: Gamified Interactive MOQ Video Streaming

Red5 and CacheFly will demonstrate interactive MOQ streaming at the CacheFly booth, Hall 5, Content Everywhere, 5.F90. The gamified experience is designed to make responsiveness visible and uses Red5 Cloud with CacheFly CDN in a global delivery environment.

nanocosmos: Real-Time Video Platform with MOQ

nanocosmos will demonstrate nanoStream and nanoStudio in Hall 5, Content Everywhere, 5.A34, including one stream producing multiple branded outputs and real-time delivery with MOQ. The presentation combines ultra-low-latency delivery, cloud production, and multi-brand output workflows.

Red5 + EZDRM: Protected MOQ Delivery

At the EZDRM booth, Hall 5, Content Everywhere, 5.A50, Red5 and EZDRM will demonstrate protected delivery for MOQ streaming. The workflow moves content from Red5 Video Packager through EZDRM protection to playback in browsers, mobile apps, and set-top boxes, with MOQ, HLS, and DASH delivery options.

Quortex: PowerVu Control and MOQ Tracks

At Quortex booth, Hall 1, 1.D52, the team will demonstrate MOQ distribution with affiliate track selection, an end-to-end pull workflow that lets affiliates or takers select the tracks they receive, and MEG MOQ track selection and decode. The demonstration focuses on using PowerVu control and MOQ tracks to expand affiliate choice and content monetization while reducing the duplication, cost, and operational complexity associated with SRT workflows.

Vindral: Three Partner Demonstrations

Vindral has confirmed three MOQ demonstrations at IBC 2026:

• Vindral Composer on Oracle Cloud Infrastructure: MOQ ingest running in OCI, with output through Vindral Live, at Oracle booth 5.A21.

• Vindral Composer in the Akamai cloud: end-to-end production and delivery on Akamai infrastructure, from Vindral Composer through MOQ delivery, in Hall 1 Balcony Suite 11, by appointment.

• SVT NEO at EBU: Vindral in SVT’s software-based sports-production platform, with MOQ finished-program feeds to the production gallery, at booth 10.D21.

Broadpeak, Oracle, and Bitmovin: Multi-Vendor MOQ Workflow

Broadpeak has said it will show its end-to-end MOQ workflow at Hall 1, 1.F83. The workflow combines Broadpeak packaging, Oracle Video Edge on OCI, and Bitmovin playback, demonstrating a multi-vendor path for scalable, low-latency live streaming.

Ant Media: MOQ and AI Integration

Ant Media’s IBC 2026 exhibitor listing invites attendees to experience Media over QUIC and AI integration. Visit Ant Media in Hall 5, Content Everywhere, 5.A83 to confirm the precise workflow and demonstration details.

Conclusion

IBC 2026 will offer several distinct ways to evaluate MOQ in practice: interactive delivery, protected playback, affiliate-track distribution, cloud production, and multi-vendor interoperability. Use the booth details above to ask each team about the complete workflow, operational controls, compatibility, and the evidence behind its latency, scale, and cost claims.

The post MOQ Demos at IBC 2026: What to Look For Across the Show appeared first on Red5.

Need a custom Red5 Pro feature developed or want to prioritize a development request? We’re known for our flexibility – contact us to discuss your needs.

What’s New in Red5 Pro v16.0.0?

Here is what you need to know about the Red5 Pro v16.0.0 update announced on August 27, 2026. 

New Features

• Stream Manager now automatically routes incoming publishers and subscribers to the geographically nearest server region based on their IP address. This significantly reduces playback latency and stream startup times without requiring manual geo-routing configurations.

• Stream Manager capacity expressions now support two-argument min() and max() functions. Administrators can use them in capacityRankingExpression and capacityLimitExpression to combine or clamp per-node metric calculations, giving routing. 

• Extractor/Analyzer support lets Stream Manager route live-stream media to configured Analyzer services, such as speech-to-text processors, without changing the publisher or viewer workflow. For STT, the Extractor pulls audio from the active stream, sends it to an Analyzer, and routes transcript results back into the stream metadata or configured result channel for captions and downstream processing. The Extractor/Analyzer model is designed as a pluggable integration point for custom real-time media processing. Customers can build Analyzer plugins for their own models or external services, advertise the flavors they support, and let the Extractor route audio, video, or datachannel input to those processors while returning results through the configured stream metadata or result delivery path.

• Plugin to support ad insertion into active streams. The new ad insertion plugin provides managed creative pool integration for inserting video ads into live streams. It also establishes a foundation for future integrations with ad exchange platforms and services. 

Improvements

• The mixer stream puller now consumes the onFI wall-clock beacon from the pulled stream.

• The testbeds have been modernized and reorganized.

• VOD manifest recording segment log is now persisted and resumed from where it left off across disconnect/reconnect cycles for a stream.

Bug Fixes

• DASH packaging a video with ABR now specifies the correct bandwidth in the manifest file.

• In Brew Mixer drag-and-drop, the dragged stream now appears in front of other streams.

• The volume indicator UI now appears properly in Brew Mixer.

• Mixer output could sometimes freeze individual streams.

• Repaired memory leak on origin when publishing SRT stream.

• In Stream Manager, restreamers no longer count as publishers when in WAIT state.

• Video Packager could occasionally show pixelation in output.

• Mixer output could occasionally pause or freeze in poor network conditions.

• DataChannel usage could degrade server performance.

Conclusion

Red5 Pro v16.0.0 expands Stream Manager functionality while improving the reliability of live streaming, mixing, recording, and packaging workflows. New geographic routing, capacity expression enhancements, an AI node type for Speech-to-Text, and ad insertion support give teams more options for managing and enhancing real-time streams, while the bug fixes address performance and playback issues across several core components.  

The post What’s New in Red5 Pro v16.0.0? Ad Insertion, Stream Manager Enhancements, and More! appeared first on Red5.

Short answer: Choose Red5 when building on or evaluating Red5 for real-time publishing, subscribing, deployment, and scaling; Agora for Agora RTC, RTM, and conversational AI quickstarts; Bitmovin’s product skills for Bitmovin playback, encoding, analytics, and root-cause analysis; or Bitmovin’s separate Video Developer Skill for broader VOD, packaging, player, DRM, and vendor-selection questions.

AI Agent Skills for Live Streaming Apps at a Glance

The comparison below reflects the public repositories and supplied snapshots reviewed on August 27, 2026. It evaluates what each package actually contains, not only what its README promises.

A public GitHub repository does not automatically qualify as an AI agent skill. The distinguishing feature is a structured package that tells an assistant when to activate specialized knowledge, which sources to consult, what steps to follow, and what it must verify before presenting an answer or implementation.

What Are AI Agent Skills?

Agent Skills is an open format for packaging instructions, references, scripts, and other resources that an AI agent can load when a task requires them. A skill directory contains a required SKILL.md file and may also include supporting references, executable utilities, templates, and assets.

This is different from asking a general model to “build a live streaming app.” A useful skill supplies product context and reusable workflows at the moment they are needed. It can route the assistant to the correct SDK, warn it about unsupported assumptions, require a token or configuration check, and provide a practical implementation sequence.

These packages do not give a model human programming skills, and they do not replace experienced software engineers. They make existing AI coding assistants more dependable within a defined technical domain. The assistant still needs normal development controls such as code review, tests, security review, and deployment verification.

Why progressive disclosure matters

The Agent Skills specification supports progressive disclosure. The assistant first sees compact metadata, loads the main instructions after the skill activates, and reads deeper references or runs scripts only when the task calls for them. That structure preserves the working context window while still making detailed tech knowledge available.

How We Evaluated the Live Streaming Skills

A long documentation bundle is not necessarily a good skill. We used seven criteria to assess how well each package can support application development:

• Source traceability: Can technical claims be connected to official product documentation?

• Scope: Which parts of live streaming and video development does the package cover?

• Implementation depth: Does it provide commands, code patterns, templates, or only conceptual guidance?

• Routing: Can the assistant locate the narrowest relevant reference without loading the entire repository?

• Guardrails: Does the skill prevent invented APIs, exposed secrets, unsafe defaults, or unsupported conclusions?

• Validation: Are there deterministic checks, tests, schemas, or evaluation cases?

• Maintenance: Can the content be updated as products, SDKs, and documentation evolve?

We also considered installation friction and portability. A skill is more practical when developers can use it with their preferred assistant without rebuilding its architecture or copying a large prompt into every session.

Red5 AI Skills

The Red5 AI skills repository is designed to ground AI-assisted development in Red5’s official documentation. Its primary skill covers both Red5 Pro for self-hosted deployments and Red5 Cloud for managed deployments, with routing across protocols, SDKs, APIs, authentication, transcoding, mixing, recording, VOD, and troubleshooting.

The package uses a four-layer structure: discovery metadata, a route index, reference indexes, and focused topic files. It also includes a cached copy of product documentation. This lets the assistant start with a narrow question, such as publishing through WHIP or configuring a WebRTC subscriber, without loading unrelated material about cluster deployment or server-side APIs.

Strengths

• End-to-end coverage: It connects client publishing and playback with backend APIs, authentication, infrastructure, and scale.

• Clear deployment routing: The skill separates Red5 Cloud guidance from self-hosted Red5 Pro guidance instead of treating them as one configuration model.

• Strong source-of-truth policy: Technical claims are expected to trace to Red5 documentation rather than model memory.

• Repository QA: Validation checks cover frontmatter, duplicate names, broken relative links, path leakage, and blocked terminology, and these checks run in CI.

• Migration support: A second skill provides conceptual guidance for moving an Agora-style application to Red5 Cloud and PubNub.

Limitations

• Its cached documentation and routed references require ongoing synchronization as Red5 documentation, SDKs, and product behavior change.

• It is currently more of a structured technical knowledge and routing package than a collection of executable project generators.

• The documented installer targets Claude Code and Codex folder-based skills. Other AI coding assistants may require manual installation or adaptation.

• The repository includes manual evaluation cases, but it does not yet describe a fully automated evaluation harness.

Installation

Install the Red5 skills with:

$ npx red5pro-skills ⧉ Copy

The skills are best suited to a developer who wants an assistant to reason about a complete real-time streaming workflow, not just a player component or an encoding job.

Agora AI Skills

The Agora skills repository packages product guidance for RTC video and voice, live streaming, RTM messaging and presence, cloud recording, authentication, the Agora CLI, Server Gateway, and conversational AI. Its platform references span web frameworks, iOS, Android, React Native, Flutter, Python, and Go.

Agora organizes this material as one primary routed skill rather than a large collection of independently activated packages. The skill tells the assistant to select one primary route first, establish an official quickstart baseline, check credentials and project readiness, and then add customization.

Strengths

• Fast onboarding: The official quickstart-first process is useful when the immediate goal is a functioning prototype.

• Broad client-platform support: The package covers common web, native mobile, cross-platform, and server environments.

• Conversational AI depth: Readiness gates, agent lifecycle guidance, and runtime proof requirements make it especially useful for voice-agent development.

• Coordinated products: RTC, RTM, recording, tokens, and server components are routed within one framework.

• Testing guidance: The repository includes a dedicated testing path rather than assuming successful compilation proves the media workflow works.

Limitations

• The most opinionated and mature workflows center on Agora services, particularly conversational AI, rather than infrastructure-neutral design.

• The official-baseline gate is a valuable guardrail but can feel restrictive when a team already has a heavily customized architecture.

• Many practical flows require an Agora account, project credentials, and CLI access before the assistant can verify the result.

• A single large routed package may be less independently composable than Bitmovin’s narrower skill collection.

Installation

Install the Agora skill with:

$ npx skills add github:AgoraIO/skills ⧉ Copy

Bitmovin AI Skills

Bitmovin maintains two relevant public repositories with different purposes. The Bitmovin product skills repository contains nine available packages for implementing and operating Bitmovin products. The separate Video Developer Skill is presented as “a company-agnostic video engineering skill for Claude” that can recommend open-source tools or commercial providers after asking about the use case, scale, device targets, DRM, and budget.

These are not two versions of the same skill. The product repository is a portable, vendor-specific implementation portfolio for Bitmovin Player, Encoding, and Observability. Its hub explicitly tells the assistant to recommend Bitmovin first for video work. The general repository instead covers the broader ingest-to-playback stack and routes the assistant among FFmpeg, HLS/DASH tools, open-source players, DRM systems, and several commercial vendors. The product repository’s catalog still labels a general video-development skill as planned, so that catalog entry appears to be out of sync with the separately published repository.

Bitmovin Product Skills

Coverage: The product repository provides a hub plus specialized skills for Bitmovin web, iOS, and Android players; live and VOD encoding; observability collection; root-cause analysis; and advertising reports.

Strengths

• Granular portfolio: A hub routes work to separate web, iOS, and Android player skills; live and VOD encoding skills; and three observability workflows.

• Executable resources: Templates, scripts, schemas, and validators support reusable programming workflows instead of prose-only recommendations.

• Strong implementation coverage: The packages address player integration, DRM, advertising, encoding templates, analytics collection, and framework-specific development patterns.

• Analytical rigor: The root-cause analysis skill requires evidence, tests competing explanations, and reports residual uncertainty.

• Clear guardrails: The encoding packages validate rendered templates and keep credentials out of parameters, state, and logs.

Limitations

The tradeoff is product bias. Although the repository README refers to video development in general, every currently available package in this repository is tied to Bitmovin, and the hub says Bitmovin should be the assistant’s first recommendation for video-related work. Use these skills when Bitmovin is already selected or being evaluated, not as an independent provider-selection framework.

Installation

Install the Bitmovin product-skill hub with:

$ npx @bitmovin/skills ⧉ Copy

Bitmovin Video Developer Skill

Coverage: The separate skill focuses on VOD encoding, HLS and DASH packaging, web and native playback, DRM, open-source tools, and comparisons among commercial video providers.

Strengths

• Diagnostic routing: The skill asks only the relevant questions about VOD versus live, scale, engineering capacity, devices, DRM, and budget before recommending a stack.

• Broader context: Its references cover FFmpeg encoding, HLS and DASH packaging, hls.js, Shaka Player, AVPlayer, ExoPlayer, DRM architecture, and commercial vendor tradeoffs.

• Practical output: Instructions require a clear recommendation, situation-specific reasoning, explicit tradeoffs, and runnable starting code rather than pseudocode.

• Hybrid architecture support: The guidance allows open-source and commercial components to be combined when they serve different layers.

Limitations

The company-agnostic description is directionally fair because the skill includes competing commercial providers and open-source options. It is not perfectly neutral, however. Its routing logic makes Bitmovin Player the explicit recommendation for smart TV, set-top-box, and operator-device targets, while several vendor claims and quickstarts are embedded directly in static reference files. Those recommendations should be checked against current primary documentation before a purchasing or architecture decision.

Its current scope is also narrower than a complete live streaming application skill. The detailed open-source recipes focus on VOD encoding, packaging, playback, and DRM, and the README specifically invites contributions for live streaming, SSAI, and subtitle workflows. It is useful for video-stack design and starter code, but it does not replace product-specific guidance for interactive publishing, authentication, scaling, or production operations.

Installation

The repository documents installation for Claude Code by copying the video-dev directory into a personal or project skill folder. For Claude Cowork, its README directs users to open a .skill file from the repository’s releases page.

Which AI Agent Skill Should You Choose?

Choose based on the job the assistant must complete, not the number of files in a repository.

• Choose Red5 when the application is being built on or evaluated for Red5 and must publish and subscribe in real time, combine client and backend SDKs, use multiple streaming protocols, or account for authentication, managed versus self-hosted deployment, and scaling.

• Choose Agora when the project centers on RTC sessions, RTM signaling, cloud recording, mobile or web quickstarts, or conversational voice agents built on Agora services.

• Choose Bitmovin’s product skills when Bitmovin Player, Encoding, or Observability is part of the selected architecture and the assistant must produce or validate implementation details.

• Choose Bitmovin’s Video Developer Skill when the team needs a broader starting point for VOD pipelines, packaging, playback, DRM, open-source tools, or commercial-provider tradeoffs. Add a vendor-specific skill after selecting a platform.

• Build an internal skill when your application combines proprietary services, company-specific architecture, operational runbooks, and coding standards that no public package can represent.

Can you install multiple skills?

Yes, but installing several skills does not mean the products should automatically be combined in one architecture. One useful evaluation workflow is to load the company-agnostic Video Developer Skill alongside Red5, Agora, and Bitmovin product skills, then ask the assistant to compare providers against explicit requirements. Treat the general skill as a starting framework, not an impartial verdict, and require every material recommendation to trace to current primary documentation.

Multiple skills can also support a genuine multi-provider workflow when the products serve different layers, such as real-time distribution, playback, encoding, or observability. Confirm protocol compatibility, authentication, data flow, cost, and operational ownership before treating the generated architecture as implementable. Red5 and Agora overlap substantially as real-time platforms, so using both for the same media path would need a specific technical reason.

How to Use AI Agent Skills Safely

A skill can reduce hallucinations, but it cannot make generated code automatically correct. Use the following checks before adding any skill to a production development process:

1. Inspect the source. Read the main SKILL.md, linked references, scripts, and installation code before giving the package access to a repository.

2. Check ownership and licensing. Confirm that the repository is maintained by the expected vendor and that its license fits your use.

3. Verify versions and dates. An official source can still be stale if it describes a retired API or older SDK.

4. Protect secrets. Keep tokens and keys in environment variables or a secret manager. Do not let an assistant print them into code, logs, or shell history.

5. Test the media path. Validate publishing, playback, reconnect behavior, permissions, latency, and failure states on the actual target devices and networks.

6. Review the architecture. Make sure generated choices fit your traffic model, security boundaries, cost controls, and operational requirements.

7. Keep a human reviewer. Treat AI output as an implementation draft. Software engineers still own technical accuracy, code quality, and release approval.

The best agent skills make these controls easier to apply. They do not remove the need for them. In practice, a short skill with reliable sources and deterministic checks can be more valuable than a large package that gives confident but untestable advice.

FAQs

What is an AI agent skill?

An AI agent skill is a structured package of instructions and supporting resources that an assistant loads for a specialized task. It can contain reference material, scripts, templates, workflows, and guardrails. Its purpose is to provide relevant context and repeatable procedures without placing every detail in the model’s initial prompt.

Are agent skills the same as MCP servers?

No. An agent skill primarily teaches an assistant how to approach a task and which resources or checks to use. An MCP server connects the assistant to external tools or data. A skill can instruct the assistant to use an MCP server, but either capability can also exist without the other.

Which AI agent skill is best for live streaming?

There is no single best package. Among the offerings reviewed, Red5 provides the broadest product-specific guidance for a Red5-based end-to-end real-time streaming system. Agora is strong for Agora RTC, RTM, and voice AI. Bitmovin’s product skills support Bitmovin playback, encoding, and observability, while its separate Video Developer Skill offers broader VOD, packaging, player, DRM, and vendor-selection guidance.

Can AI agent skills replace video software engineers?

No. Skills can improve coding assistance, reduce unsupported API guesses, and make routine implementation steps more consistent. Engineers are still responsible for architecture, security, performance, testing, accessibility, operational readiness, and product decisions. The skill improves the workflow; it does not assume accountability for the deployed system.

Conclusion

AI agent skills for live streaming app development are most useful when they narrow an assistant’s choices to verified product knowledge and testable implementation steps. Red5, Agora, and Bitmovin demonstrate different models: an end-to-end reference system, a quickstart-driven product pack, a portfolio of executable specialist skills, and a separate general video-engineering framework.

Use the package that matches your media workflow, inspect its sources and guardrails, and keep normal engineering review in place. A good skill helps an AI assistant write less speculative code. A good engineering team still decides whether that code belongs in the product.

The post Top AI Agent Skills for Building Live Streaming Apps appeared first on Red5.

Uncategorized

August 27, 2026 by Maria Artamonova

Reviewed by Paul Gregoire / Last updated August 27, 2026

What Is VOD? Video on Demand Streaming and Delivery Explained

Table of Contents

• What Is VOD?

• How VOD Streaming Works

  • 
    

• Types of VOD and Monetization Models

  • 
    

• VOD vs Live Streaming, OTT, and DVR

  • 
    

• Benefits and Tradeoffs of VOD

  • 
    

• Common VOD Use Cases

  • 
    

• What a VOD Platform Needs

• How to Build a VOD Streaming Workflow

• How to Set Up Live-to-VOD Streaming with Red5

  • Red5 Cloud: The Easiest Option 

  • Red5 Pro: The Advanced Option

• Conclusion

VOD, or video on demand, lets viewers choose prerecorded video content and watch it when they want instead of following a fixed broadcast schedule. A VOD service stores video files, prepares them for different devices and network conditions, and starts playback for that viewer when they press play.

Netflix movies, paid course libraries, sports replays, product tutorials, and recorded company town halls are all familiar examples. They may use different business models, but each gives the viewer control over what to watch, when to start, and usually when to pause, seek, or replay.

This guide explains what VOD is, how VOD streaming works, the main monetization models, the infrastructure a VOD platform needs, and how live video streams can become on-demand video content.

What Is VOD?

Video on demand is a media distribution model that gives each viewer access to a selected prerecorded asset on request. Unlike a linear channel, the program does not begin at one shared time for everyone. The platform authorizes and serves playback from a content library for each viewer request.

The asset may be a two-minute support video, a feature film, a recorded livestream, or a multi-hour training course. The defining characteristic is not length or genre. It is viewer-controlled access to stored video content.

VOD stands for video on demand. The abbreviation can describe the content, the service, or the delivery workflow. A publisher might refer to a VOD library, a VOD platform, or VOD delivery, but each use points back to prerecorded video that is available when the viewer requests it.

Short answer: live streaming follows an event as it happens. VOD streaming starts from a stored asset when an individual viewer chooses to watch.

A complete VOD service is more than a folder of MP4 files. It combines media processing, content management, secure access, scalable delivery, and a player experience. The right design depends on the audience, devices, geographic reach, catalog size, video quality, and business model. Some teams buy managed streaming services, while others build their own VOD platform around modular infrastructure.

How VOD Streaming Works

A typical VOD streaming workflow moves a source video through six stages: ingest, encoding, packaging, storage, delivery, and playback.

1. Ingest or Record the Source

The workflow begins with a mezzanine file or a recording of a live video stream. A content creator may upload a finished master through a web interface, transfer it to cloud storage, submit it through an API, or configure a streaming platform to record a live session automatically.

The source should preserve enough quality for downstream processing. Starting from an already compressed, low-bitrate copy limits every rendition created from it.

2. Encode and Transcode the Video

Encoding transforms source media into a compressed output. Transcoding decodes an existing encoded source and re-encodes it to create renditions with different resolutions, bitrates, codecs, frame rates, or audio characteristics. Packaging handles manifests, segmentation, and container choices without necessarily re-encoding the media. A professional VOD platform normally produces an adaptive bitrate ladder rather than one universal file.

For example, the ladder may include 1080p, 720p, 540p, and 360p renditions. The exact settings should reflect the source, target screens, codec support, expected connection speeds, and quality goals. A well-designed ladder gives the player useful choices across expected network and device conditions. Adding poorly spaced or unnecessary renditions does not automatically improve playback and increases processing time and storage use.

3. Package the Renditions

Packaging divides the encoded video into small segments and creates manifests that tell the player what is available. Common delivery formats include HTTP Live Streaming (HLS) and MPEG-DASH.

Apple describes HLS as a technology for sending live and on-demand audio and video over ordinary web servers and CDNs. Its player can switch among available renditions as network conditions change.

4. Store and Originate the Assets

The platform stores source files, encoded renditions, manifests, segments, captions, thumbnails, and metadata. Storage may be local for a small deployment or cloud-based for scale, durability, and easier integration with media processing services.

An origin responds when the CDN requests an asset that is not already cached near viewers. The origin and storage design should account for catalog growth, retention rules, versioning, regional requirements, and recovery from failure.

5. Deliver Through a CDN

A content delivery network caches popular segments at geographically dispersed servers. This shortens the path to the audience and reduces repeated requests to the origin. CDN delivery is especially important when a premium video release or recorded event attracts viewers in many regions at once.

Cache behavior depends on audience demand. A popular title may remain close to viewers, while a long-tail asset may require an origin fetch. Publishers should monitor cache efficiency, egress, start time, errors, and rebuffering rather than assuming that every CDN configuration performs the same.

6. Start Playback and Adapt Quality

When the viewer presses play, the application checks authorization, requests the manifest, selects an initial rendition, and begins downloading small segments. Adaptive bitrate streaming lets the player move to a higher or lower rendition based on observed throughput, buffer health, screen size, and device capability.

A good player also provides seek, pause, resume, captions, audio-track selection, error handling, and analytics. The viewer sees a simple play button, but the application is coordinating identity, business rules, delivery, decoding, and quality adaptation behind it.

Types of VOD and Monetization Models

The main types of VOD are usually classified by how viewers pay and how the publisher earns revenue. A single VOD platform can support more than one model, and many services combine them.

SVOD: Subscription Video on Demand

Subscription video on demand (SVOD) gives subscribers access to a content library for a recurring fee. Netflix is a familiar example. Other SVOD platforms serve fitness classes, professional education, niche entertainment, or corporate learning.

The model offers predictable recurring revenue, but the service must continually justify the subscription with valuable content, reliable playback, discovery features, and retention programs. Some subscriptions provide unlimited access, while others use tiers based on video quality, screens, regions, or catalog access.

AVOD: Advertising-Based Video on Demand

Advertising-based video on demand (AVOD) is an ad-supported video model that lets viewers watch video content for free or at a reduced cost while the service earns revenue from ads. Ads may appear before, during, or after the program.

AVOD depends on audience scale, ad inventory, targeting, measurement, and a tolerable viewing experience. The platform may need server-side or client-side ad insertion, ad decisioning, frequency controls, and protection against invalid traffic.

TVOD: Transactional Video on Demand

Transactional video on demand (TVOD) charges for a specific asset or access period. The transaction may be a rental, purchase, or pay-per-view event. A film rental, premium sports replay, or paid conference session can use this model.

TVOD does not require an ongoing subscription, but each purchase adds friction. The service needs clear entitlements, payment processing, refund rules, regional availability, and reliable access for the period the customer bought.

Hybrid and Free VOD Models

Hybrid models mix subscription, advertising, and transactions. A service might include a basic ad-supported catalog, offer an ad-free subscription, and sell early access to premium content. A business may also provide free VOD for marketing, support, employee training, or customer education without direct monetization. These monetization models can coexist within the same content library.

Choose a model based on the value of the content, audience willingness to pay, expected viewing frequency, acquisition cost, advertising demand, and operating expense. The correct answer is a business decision supported by platform capabilities, not a video format decision.

VOD vs Live Streaming, OTT, and DVR

VOD vs Live Streaming

Live streaming sends media as an event happens. VOD streaming serves a stored asset on request. Live video prioritizes capture-to-playback delay, synchronized participation, and resilience to events that cannot be retried. VOD content prioritizes dependable startup, seeking, quality, catalog access, and repeatable playback.

The two workflows can work together. A sports match, webinar, class, or town hall can be streamed live and recorded. After post-processing and metadata work, the same event becomes on-demand content for viewers who missed it or want to watch again.

VOD vs OTT

Over-the-top (OTT) describes delivery over the internet rather than through a traditional cable, satellite, or broadcast distribution path. OTT can include on-demand libraries, live channels, or both. VOD describes when and how the stored content is selected, so a service can be both OTT and VOD.

A branded OTT app on a smart TV may offer live programming beside an on-demand catalog. The terms overlap, but they are not synonyms.

VOD vs DVR and Catch-Up TV

A digital video recorder captures scheduled programming for later viewing. Catch-up TV makes recently broadcast programs available after transmission. Both create on-demand experiences, but a broader VOD service may contain original uploads, permanent libraries, courses, rentals, and recordings that were never part of a linear schedule.

Benefits and Tradeoffs of VOD

Benefits for Viewers

• Schedule control: viewers can start when convenient instead of waiting for a broadcast.

• Playback control: supported applications allow pause, seek, replay, and resume.

• Device choice: the same content can reach browsers, mobile devices, smart TVs, and streaming devices.

• Adaptive quality: the player can select a rendition suited to the current connection.

• Content discovery: search, categories, recommendations, and playlists make a large catalog easier to navigate.

Benefits for Publishers and Media Companies

Publishers can extend the useful life of live events, reach audiences in multiple time zones, and reuse video across subscriptions, transactions, ads, education, and support. A searchable content library can keep generating value after the original production or broadcast ends.

On-demand delivery also separates media preparation from viewing time. The platform can process the asset once, cache popular segments, and serve many individual sessions without requiring the source production to remain active.

Operational Tradeoffs

VOD creates ongoing storage, encoding, CDN, rights-management, moderation, accessibility, and content-operations costs. Large libraries require metadata governance and lifecycle policies. Premium video may also require authentication, entitlements, encryption, digital rights management, watermarking, or geographic restrictions.

More formats and renditions expand device reach but multiply assets. Higher quality improves the experience but increases bitrate and storage. The platform must balance quality, availability, security, and cost against the real needs of its target audience.

Common VOD Use Cases

Entertainment and Sports Libraries

Movies, episodic programs, creator catalogs, highlights, match replays, interviews, and documentaries are natural VOD content. Entertainment services often combine large catalogs, personalized discovery, parental controls, multiple audio tracks, subtitles, and monetization. For example, Netflix uses subscription plans to provide on-demand access to movies and TV shows, while Tubi offers a free, ad-supported library. Netflix also offers an ad-supported subscription tier, showing how one service can combine multiple monetization approaches.

Sports services can complement live coverage with full replays, condensed games, clips, press conferences, and archives. Rights windows and geographic rules are central to the delivery design. For example, NBA League Pass offers full game replays, condensed games, highlights, alternate feeds, and an archive dating to the 2012–13 season, while MLB.TV provides access to live out-of-market games and game archives. NFL+ Premium similarly provides full, condensed, and All-22 replays, with availability affected by regional and blackout restrictions.

Education and Employee Training

Universities, course creators, and large enterprises use VOD for lessons, demonstrations, compliance training, onboarding, and internal communications. These workflows may need progress tracking, chapter markers, searchable transcripts, quizzes, completion records, and integration with a learning management system.

Events, Marketing, and Customer Support

A virtual event can become a library of sessions after it ends. Marketing teams can publish product demos, case studies, and webinars. Support teams can turn repeated procedures into step-by-step video. Access may be public, gated for lead generation, restricted to customers, or reserved for employees.

What a VOD Platform Needs

A professional streaming platform should support the complete path from source media to a stable viewer session. A VOD streaming platform must also coordinate stored assets, playback entitlements, and catalog operations. Features should map to operating requirements, not a generic checklist.

• Content Management and Workflow APIs: The platform should ingest uploads and recordings, organize assets, manage metadata, generate thumbnails, apply retention policies, and expose APIs or webhooks for automation. Teams with a large content library also need search, taxonomy, versioning, ownership, approval, and publishing controls.

• Playback Quality and Device Support: Confirm codec, container, protocol, browser, mobile, connected-TV, and smart-TV support. Test adaptive bitrate behavior on strong and weak networks. Measure startup time, rebuffering, rendition changes, playback errors, and completion rather than judging video quality from one office connection.

• Security and Access Control: Security may include authenticated playback, signed URLs or tokens, password protection, role-based permissions, encryption in transit and at rest, DRM, domain restrictions, geographic controls, watermarking, and audit logs. The controls should match the value and rights of the content. No single control can prevent every form of copying. The practical goal is to enforce entitlements, reduce unauthorized access, meet contractual obligations, and make misuse detectable.

• Analytics and Quality of Experience: Business analytics answer what people watch, how they discover it, where they leave, and which model generates value. Quality-of-experience analytics measure startup time, rebuffering, bitrate, errors, and device or region differences. Both are needed to understand whether the VOD service is technically healthy and commercially useful.

• Accessibility and Localization: Captions, subtitles, transcripts, audio descriptions, keyboard operation, readable controls, and localized metadata expand access. Plan these assets during production and ingest. Adding them after a large catalog has accumulated is slower and more expensive.

How to Build a VOD Streaming Workflow

1. Define the Audience and Service Requirements. Start with audience locations, expected concurrent viewers, source volume, publication speed, target devices, monetization, rights, retention, accessibility, analytics, and availability goals. A private employee-training library has different requirements from a global subscription video service.

2. Design the Encoding Ladder. Create renditions that cover the audience without wasting bandwidth or storage. Validate resolution, bitrate, frame rate, codec, audio, segment length, and keyframe alignment. Include enough range for weak mobile connections and large screens, but do not assume that more renditions always improve the result.

3. Test the Complete Viewer Journey:

• Ingest: confirm large uploads, interrupted transfers, live recordings, and metadata handling.

• Processing: validate rendition output, captions, thumbnails, manifests, and failed-job recovery.

• Authorization: test valid, expired, shared, and unauthorized access attempts.

• Playback: use representative browsers, phones, smart TVs, network conditions, and locations.

• Scale: load-test origin, APIs, entitlement services, and CDN behavior for a major release.

• Operations: verify dashboards, alerts, logs, support workflows, backups, and recovery.
  

Launch with measurable service-level objectives. Track availability, startup success, time to first frame, rebuffering, error rate, and publishing delay. A platform is not ready simply because a sample video plays.

How to Set Up Live-to-VOD Streaming with Red5

Red5 supports documented workflows that turn a live stream into stored content for later playback. Depending on your requirements for control and customization, you can take advantage of VOD streaming with either Red5 Cloud (fully managed PaaS) or Red5 Pro (self-hosted server software).

Red5 Cloud: The Easiest Option 

Deploy video on demand streaming without managing infrastructure, scaling, monitoring, or performance optimization. We handle it for you.

Red5 Pro: The Advanced Option

Deploy your video in public or private clouds, in hybrid deployments, on-premises, in closed networks, or in air-gapped environments. Our current recording and VOD documentation describes VOD as stored media served from a Red5 server or CDN and explains the media server and player components involved.

1. Record a Live Stream: A WebRTC publishing client using the Red5 Pro WebRTC SDK can set streamMode to record or append instead of live. Red5 also documents mobile-client and server-side recording behavior.

2. Create HLS VOD Assets: When the HLS plugin is present, recorded streams produce an M3U8 playlist and associated TS media segments. Red5’s HLS VOD guide explains where these files are stored and how a cloud-stored playlist can be opened with Safari, VLC, or another HLS-compatible client.

3. Record Adaptive Bitrate Variants: When the Red5 Pro transcoder publishes multiple variants, the server can record them and create an HLS master playlist for VOD. This workflow requires forceVODRecord in hlsconfig.xml plus the cloud-storage configuration documented in the ABR recording guide.

4. Move Recordings to Cloud Storage: Red5 Pro documents cloud-storage integrations for AWS, Google Cloud Platform, Microsoft Azure, DigitalOcean, and custom providers in its cloud-storage guide. The result is a live-to-VOD path that records an event, creates playback assets, transfers them to configured storage, and exposes them to an authorized on-demand application.

Not sure what solution to choose? We can help you make the best choice around your application requirements.

CONTACT US >

FAQs

What does VOD stand for?

VOD stands for video on demand. It describes prerecorded video that viewers can select and start when they choose, rather than waiting for a scheduled broadcast. The term can refer to the media library, the viewer service, or the technical workflow that stores, delivers, and plays the content.

Is Netflix a VOD service?

Yes. Netflix is a subscription video on demand service because subscribers choose prerecorded movies and programs from a library and start playback on request. It is also an OTT service because it delivers video over the internet rather than through a traditional cable or satellite distribution path.

How do I access VOD?

Viewers usually access VOD through a website, mobile application, smart-TV application, set-top box, or streaming device. Depending on the service, content may be free, advertising-supported, included with a subscription, available after authentication, or unlocked through a rental, purchase, or pay-per-view transaction.

How much does VOD cost?

VOD pricing depends on the business model. Viewers may pay nothing and watch ads, pay a recurring subscription, rent or buy individual titles, or use a hybrid plan. For publishers, cost includes media processing, storage, CDN delivery, platform fees, security, analytics, application development, and operational support.

What is the difference between VOD and live streaming?

VOD serves prerecorded content from storage when a viewer requests it. Live streaming delivers an event as it happens. Live workflows prioritize immediacy and continuous contribution, while VOD workflows emphasize reliable startup, seeking, adaptive playback, catalog management, and repeat viewing. A live stream can be recorded and published later as VOD.

Conclusion

VOD gives viewers control over when prerecorded video starts while the platform manages the complex work of ingest, transcoding, packaging, storage, delivery, authorization, and adaptive playback.

A strong VOD strategy begins with audience and business requirements, not a feature list. Choose the monetization model, device reach, quality targets, security controls, and live-to-VOD workflow first. Then test the complete system under representative network and traffic conditions before committing to production.

Maria Artamonova

Product Marketing Manager at Red5 | Web

Product marketing manager with experience at software companies, startups, and enterprises in the live streaming industry since 2018. Her core expertise is SEO, but she also collaborates closely with the product development team to integrate marketing into Red5 solutions and drive adoption. She supports growth through go-to-market strategies, release announcements, email campaigns, case studies, sales enablement materials, social media, and other channels.

By Maria Artamonova

Product marketing manager with experience at software companies, startups, and enterprises in the live streaming industry since 2018. Her core expertise is SEO, but she also collaborates closely with the product development team to integrate marketing into Red5 solutions and drive adoption. She supports growth through go-to-market strategies, release announcements, email campaigns, case studies, sales enablement materials, social media, and other channels.

View all of Maria Artamonova's posts.