DEV Community: Red5

Consensus on a MOQ Media Layer Player Framework Should Speed Market Adoption

Maria Artamonova — Fri, 01 May 2026 13:08:54 +0000

Modular Red5 Template Is Open-Source Path to Multiple Streaming Formats

Introduction

Amid intensifying demand for the interoperable approach to next-generation streaming specified by the emerging MOQ standard there’s a lot riding on the market’s ability to determine how payloads will be formatted in the MOQ Media Layer for distribution and playback.

Happily, we can report that Red5 has garnered significant support for a way forward that relies on a MOQ player template we’re calling Playa. As a freely available open-source solution, Playa has the flexibility to accommodate configurations of players for device playback of virtually any MOQ-compatible streaming format operating over the MOQ Media Layer, which in International Standards Organization (ISO) parlance is the application layer that rides on the transport layer in internet communications.

This has been a top priority in our work as a founding member of the OpenMOQ Software Consortium, an ad hoc body separated from but closely aligned with the Internet Engineering Task Force (IETF), which is overseeing MOQ standardization. Now, with Playa emerging as the OpenMOQ Consortium’s leading candidate for formatting MOQ stream playback, the stage is set for widespread experimentation that will expedite commercial rollouts once the MOQ Transport (MOQT) standard is finalized later this year.

There’s been a lot of confusion about what MOQ is owing to its origins as an acronym for Media over QUIC, which has alternative meanings related to emerging proprietary platforms that rely on QUIC transport and to use of the QUIC protocol as the default transport mode with version 3 of conventional Hypertext Transfer Protocol (HTTP/3) streaming. IETF hopes to distinguish what it’s doing by using MOQ as a free-standing label for a new platform, which, as explained in our What is MOQ blog, avoids the complexity and error-prone request-response method used with the dominant HTTP streaming system while eliminating the set-up and other complications intrinsic to real-time streaming via WebRTC.

Moreover, the new standard provides a way to automatically tune end-to-end latencies to whatever levels meet user requirements, including real-time interactive streaming use cases that need support for latencies registering at or below 300ms. And, already, MOQ has been made compatible with leading Web browsers, currently including Google Chrome, Microsoft Edge, Mozilla Firefox and Apple Safari, which largely eliminates the need for client plug-in software.

Red5 and the other OpenMOQ Consortium founders, including Akamai, CDN77, Cisco, Synamedia and YouTube, are among a growing host of streaming providers and users worldwide who are wholeheartedly behind MOQ. We all recognize that an interoperable, tunable approach to structuring a new streaming network foundation is the fastest path to unleashing the full power of market forces seeking to exploit real-time video streaming at mass scales on an as-needed basis.

The industry is moving rapidly toward proving the point with preparations for MOQ underway on many fronts. We’ve officially launched our MOQ capabilities and are starting with a limited beta that is not publicly available yet. Access is granted on an individual basis to make sure each deployment is aligned with a specific use case. This initial phase is intentionally selective so we can fine-tune the solution around the scenarios that matter most right now, including real-time latency and delivering to geographically distributed audiences at one-to-many scale. More about this in Chris Allen’s LinkedIn post. This will lead to full commercial rollout by mid-summer.

Join our MOQ Beta

At the same time, we’re proceeding full steam ahead with serving real-time streaming customers with our global implementations of WebRTC transport utilizing XDN Architecture in our Red5 Cloud service and in customer-mounted multi-cloud iterations supported by Red5 SDKs. How all this works in bringing a broad array of use cases to life with our portfolio of TrueTime™ application toolsets is well documented on our website.

In the discussion that follows we explore where things stand with MOQ player development. Along with explaining Playa, we’ll look at other early initiatives and share thoughts about how the ones we’re familiar with might work with Playa. And we explain the steps Red5 has taken with our partners to enable early implementations of MOQ at global scales.

The discussion concludes with consideration of what can be achieved with use of the standard based on current MOQ Transport specifications and whether some real-time use cases will be best left to continued reliance on WebRTC. As shall be seen, from where we sit today it looks like MOQ will play a major role in normalizing real-time streaming across the global consumer markets while leaving video calling along with many applications in the enterprise, public safety, military and other commercial domains to execution over WebRTC transport.

The State of Play in MOQ Evolution

Standards, especially those like MOQ built on open-source technology, ensure the interoperability among whole systems and their components that’s essential to expediting adoption of new approaches to operating over the internet. But, as a community-driven process involving an unlimited flow of tech contributions and opinions, standards-building typically takes a long time.

That hasn’t been the case with MOQ, which has reached an advanced stage of development in a remarkably short time, going from initiation to near completion in less than four years. MOQ Transport, the foundation for the new platform, is going through final revisions with expectations that the standard will be finalized by mid-summer.

As described in the What is MOQ blog we referenced in the introduction, MOQ Transport determines how sessions linking end users to servers are set up and terminated and how binary-coded descriptions of payload segment parameters, destination IDs, time stamps and routing directions are conveyed in transport packet headers at the front end of the payload segments. The platform relies on a system of 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 along the way, which greatly expands the volume of streams that can be handled by relay servers.

Adding to the versatility, tunable latencies range from real-time at 200-400ms to what developers call “interactive live” at 2 seconds, which might be sufficient for some interactive applications, to “conservative live” maintaining persistent HD, 4K or, eventually, 8K quality at 5 seconds. Moreover, CDN operators can design their relay caches to support recording live content for short-term replay and catchup, and there’s also support for bringing long-term storage into play for sending live content to VOD archives and cloud DVR platforms.

At the media layer there’s no limit to the variety of streaming formats that can be devised for MOQ instances insofar as the MOQ Media Layer is decoupled from the Transport Layer, which allows CDN operators to offer MOQ Transport as a service while freeing their customers to configure streaming formats for any use cases they want to support. This opens opportunities not only for streaming formats targeting mass market applications but for niche formats as well, including video-free versions such as might be needed for chat services, autonomous vehicle operations, industrial IoT or smart city management.

In the case of mass market video streaming applications, MOQ Media Layer-compatible streaming formats will 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 for playback by media players running on receiving devices. IETF is developing a two-pronged standard for one such streaming format, formerly encapsulated as a single format called the WARP Streaming Format but now divided to accommodate two versions for use with and without the package framing known as Common Media Application Format (CMAF).

The different approaches to CMAF are the only thing that distinguishes what’s now known as MOQ Streaming Format (MSF) from the version dubbed CMSF, where the “C” stands for CMAF. Both versions are meant to provide an IETF-standardized version of a MOQ streaming format that can support the preponderance of use cases that will be flowing over MOQ Transport.

As described by the IETF’s MOQ Working Group, MSF targets real-time and interactive levels of live payloads as well as VOD content by using the IETF’s Low Overhead Media Container (LOC) protocol as a light-weight approach to stream-layer packaging that aligns with media formats using WebCodecs, which is a standard defining interfaces with encoders and decoders used in internet communications. CMSF adds CMAF as an optional alternative to relying on LOC.

Both define how what’s known as a catalog communicates information describing publishers’ output, and it specifies:

how content should be packaged, encrypted and signaled;
the use of latencies and the level of prioritization accorded real-time transmissions;
details pertaining to broadcast workflows and how they’re initiated and terminated, and
the parameters directing devices’ execution of ABR profile switching.

As to what other MOQ streaming formats might be in the offing, much will be revealed as participants in the development process introduce media players tailored to their constituents’ needs. The good news is that, at this point, Red5 and others can confidently implement infrastructure for testing MOQ applications at the transport level knowing that users will have access to MOQ media players that can execute playback of their payloads in an open-source, interoperable environment that maximizes their market reach.

Playa and MOQ Player Development

This is where the efforts of the OpenMOQ Software Consortium are paying off with its goal of fostering collaboration on development and accelerated deployment of open-source solutions tied to MOQ Transport. Along with the founding members listed in the introduction, consortium membership has expanded to include Bitmovin, qualabs, Vindral, Wowza, Austria’s University of Klagenfurt, and Özyeğin Üniversity in Istanbul.

Majority consensus among these key players that our new Playa open-source software stack provides a flexible template for tailoring browser-supported players specific to various streaming formats signals there’s now a way forward to begin working with MOQ in the real world.

Consortium support fuels our work with MOQ developers within and outside the consortium who appreciate what the functionalities embodied in Playa architecture mean to their own player development goals.

Six Known Options

At present we’re aware of six initiatives that have produced or are close to completing MOQ players. Some are well known to us and others we’re still waiting to learn more about. As described in this blog, the list includes:

Moq-js, which is the player for MOQ Lite – As its name implies, MOQ Lite is a subset of MOQ Transport developed by former Twitch and Discord engineer Luke Curley to accomplish MOQ calls with elimination of some requirements in the protocol stack without undermining basic functionalities supporting live multidirectional streaming. Most notably, it eliminates the MOQT Fetch process used for VOD and DVR scrubbing, falling back instead on HTTP streaming architecture for those applications. We’ve been working with Curley to ensure compatibility of the Moq-js player with Playa. It appears that CDN operators who want to take advantage of MOQ Lite and the full implementation of MOQT will need to dedicate resources specific to each.
Moq-encoder-player by Meta – This is another project Red5 has been working with, in this case to facilitate Meta’s development of a browser-supported player that’s devoted to implementing a live video and audio encoder to be used in creating and consuming MOQ streams. As currently constituted, the player is meant to provide a minimal platform to help with testing MOQ interoperability. But the project means Meta is likely to be putting its considerable clout behind MOQ.
Player Web X by Bitmovin – This is the player framework Bitmovin has created for developers to use as a way to build players with superior speed and performance efficiency in multiple streaming domains, including legacy HLS and Dash as well as MOQ. Bitmovin has announced Player Web X will be available for use with the MOQ relay system Cloudflare has implemented on its global CDN, presumably in compatibility with MSF and possibly other MOQ streaming formats as they emerge. While the OpenMOQ Consortium’s members, including Bitmovin, are committed to the open-source agenda pertaining to creating a streaming format running over MOQT, the mandate leaves room for use of proprietary players or other extensions that members bring to the table. At this point the long-standing Player Web X framework is not open-sourced, but it’s possible at least some aspects to the MOQ version could make use of the Playa template to streamline its interactions with MOQT.
MOQtail by a team affiliated with consortium member Özyeğin University and led by Professor Ali C. Begen – Now on Draft 14, MOQtail, which works with CMSF, is one of the longest running MOQ player projects with a foundation in Apache 2.0 licensing. While it has not gained much traction with community adoption, it has benefitted from sponsorship provided by Akamai, AWS and Cisco. One of the player’s distinguishing characteristics is that it supports both MSF and a version of MSF known as CMSF, which utilizes the Common Media Application Format (CMAF). The IETF MOQ Working Group has dropped CMSF from its MSF specifications, but, as described below, we provide support for CMAF in Playa. It remains to be seen whether MOQtail ends up adopting the Playa framework.
WARP Player by Eyevinn Technology – This is a fairly new project initiated by Eyevinn, an M&E-focused video streaming technology consultancy and platform builder based in Stockholm. The player is designed to only work with CMAF-compatible streaming formats, including CMSF. We’ve not had any interactions with the Eyevinn development team to assess what the thinking there is about working within the Playa framework.
Shaka Player – This is a general-purpose player initiative originally undertaken as an open-source project at Google centered on support for HLS and DASH in Web, Android and TV playback scenarios. With introduction of proprietary elements deemed beneficial to the player Google relinquished control to an independent community of engineers, who introduced support for MOQ in Q1 2026 in what is now known as the Shaka Project, which also includes the Shaka Packager and Streamer. The effort is aimed at ensuring cutting edge advancements like surround sound can be implemented with MOQ player support compatible with CMSF and licensed through Apache 2.0.

We also note there’s work being done within the consortium on Media Layer components targeted specifically to the contribution segment of MOQ Transport involving publishers who are feeding their content to multiple affiliates for distribution to their audiences. This is an area of development unrelated to the distribution leg and client players that involves consortium co-founder Synamedia. They’re introducing a unified playout platform capable of delivering publishers’ content via MOQ Transport to affiliates in whatever mode they’re using to reach end users, whether it’s via MOQ, HLS and DASH streams or traditional MPEG TV channels.

The Playa Connection

Now with Playa serving as the OpenMOQ Consortium-endorsed framework for MOQ player development all of these initiatives and any others that come along can benefit from a structure that modularly encompasses all the elements that might be needed to build a MOQ player. Developers can construct their pipelines using whatever components they need with a great deal of flexibility in the selection of external tools for execution of Playa-compatible functionalities.

In other words, there’s something for everyone, including developers of MOQ streaming formats that no one in the community is yet aware of. Following is a brief summary of how Playa makes this possible, all in the context of conforming to MOQT specifications.

Along with supporting modularly independent use of components, we adhered to design principles that include:

Testability of processing and pipeline logic independent of platform-specific decoding and API rendering,
Framework compatibility with independent UIs and state-based frameworks used in providing rendering targets,
Extensibility through use of pluggable extension points for object transforms, recovery policies and handling application-specific events.

The Playa architecture defines functional MOQ player blocks related to:

Managing MOQ Transport with support for both QUIC and WebTransport as well as stream multiplexing,
Session management,
Catalog parsing and track enumeration,
Managing packaging,
Maintaining stable performance over the media pipeline through jitter buffering, gap detection, A/V synchronization and control over decoder states,
Rendering video and audio with frame timing,
Quality control with ABR track selection and switching,
Recovery involving prescribed modes of error detection, escalation and reconnection.

Some other highlights include:

Packaging – The player must support either LOC or CMAF but preferably both.
Access authentication – This should follow principles defined for MOQ Relay Requirements with support for CAT-4-MOQ token usage and/or Privacy Pass Authentication recommended as well.
Security – All connections must use TLS 1.3+ as required by QUIC, and there should be support for securing development modes, such as self-signed certificate hashes for WebTransport.
MOQT version support – The player must support at least version 14 or 16 of the latest MOQT drafts with both recommended to ensure maximum interoperability during specification evolution.
Observability – The player should expose operational metrics (time to first frame, stall count, latency, quality switches) and support event tracing per the MOQT qlog specification. Real-time delivery quality diagnostics (jitter, latency) are recommended for relay assessment and operational monitoring.

Red5’s Role in Enabling Use of MOQ over Partner CDNs

As of Q2 2026, the time has come for the beta testing ahead of MOQ Transport standard approval that will allow early adopters to quickly implement full-scale commercial operations. We can assume that any tweaks that might arise with finalization of the standard can be accommodated without disrupting what we and others are putting in place now.

As mentioned earlier, we’ve begun supplying global reach for MOQ operations over CacheFly’s CDN with an eye toward expanding the XDN-anchored MOQ CDN ecosystem over time. We’re employing XDN multiprotocol ingestion and transcoding technology to enable MOQ-packaged payloads delivered from sources over Web, SRT, Zixi, RTMP, RTSP or MPEG-TS streams to be ingested onto CDNs with multiple bitrate profiles matched to adaptive bitrate (ABR) ladders used in conventional streaming.

In CacheFly’s case the CDN is integrated with Red5-supplied MOQ relay nodes that enable multicasting of the payloads in real time to all session-targeted regions served by its network. Red5 Cloud MOQ customers’ end users will be served over access networks for playback by devices equipped with our MOQ player software.

MOQ Transport and Media Layer integrations with XDN Architecture on these and future partner CDNs make it possible for customers experimenting with MOQ to achieve the full range of multidirectional real-time streaming capabilities we’ve long supported with our use of WebRTC. As explained at length in this blog and elsewhere on our website, execution of WebRTC transport on XDN Architecture enables multidirectional streaming with end-to-end latencies registering at 250ms or less.

Red5’s Support for Optimal Hybrid Use of MOQT with WebRTC

The need for such MOQ/WebRTC integrations reflects the fact that a fully standardized environment for working with MOQ remains a work in progress, including further clarification as to the range of use cases that MOQ will support. At this point, MOQ doesn’t support the echo and other noise cancellations essential to videoconferencing, and the mechanisms for bringing users’ video outputs into synchronized operation with the multicast MOQ streams have yet to be fully articulated in the MOQ Transport specifications.

By applying Red5’s mixer and transcoding solutions across the MOQ and WebRTC stream flows while enabling fallback to HLS when devices aren’t using browsers or plugins supporting the other protocols, XDN Architecture serves as the protocol-agnostic glue that maximizes streaming flexibility. Customers using CacheFly or any other CDNs we partner with can rely on MOQ instead of WebRTC for unidirectional real-time streaming at massive scales while seamlessly bringing WebRTC and our TrueTime Meetings™ platform into play in any given session to enable synchronized real-time video calling among subsets of users.

This makes it easy, for example, to serve a mass audience with live-streamed sports payloads packaged in the MOQ Media Layer while adding seamlessly initiated and accessed watch party features supported by WebRTC. In fact, Red5 Cloud and Red5 Pro customers leveraging MOQ over these CDNs will have recourse to implementing any service strategy enabled by the wide range of real-time interactive streaming applications supported by all of our TrueTime Solutions™ and other innovations.

Conclusion

The progress in MOQT standardization and support for payload configurations and playback over the MOQ Media Layer has set the stage for widescale testing in the runup to commercial rollouts. With no limit on the variety of streaming formats and players that can be developed using the framework embodied in the modularized Playa template, every segment of the vast video streaming ecosystem, from the mass consumer markets to the smallest enterprise and institutional niches, can now prepare to benefit from a standardized approach to next-generation streaming that removes the latency impediments of the past.

But there’s no denying it will take a good amount of time before support for MOQ-based streaming is as readily available as today’s HTTP-based streaming infrastructure. And it remains to be seen how far MOQ can go toward supporting seamless instantiation of real-time interactive video communications with unidirectional streaming on par with what can be done with Red5’s TrueTime Meeting™ or any other multidirectional video implementation over WebRTC on XDN infrastructure.

Our goal in throwing full support behind MOQ is to ensure that no customer has to await emergence of an optimal all-MOQ environment, if there ever is one, to achieve their goals with real-time streaming. Whatever the use case might be, the option to employ XDN Architecture through the Red5 Cloud service or use of Red5 SDKs at any scale is immediately at hand with the ability to launch testing with MOQ and eventually to transition to use of MOQ to whatever extent makes sense.

For now, with our multiprotocol streaming support extending to distribution over HTTP based protocols like HLS, DASH, LL-HLS and LL-DASH via our partnership with CacheFly, XDN Architecture provides the protocol-agnostic platform that can be used to eliminate the operational silos of the past. And once ubiquitous availability of MOQ streaming infrastructure with support for tunable latencies makes it possible to meet that goal, XDN Architecture will continue to provide the optimal operational environment for getting the most out of MOQ.

How to Connect Your Drone or IP Camera Feeds to Red5

Maria Artamonova — Wed, 29 Apr 2026 21:36:58 +0000

Since it comes up so often during the course of my week, I want to share a few simple options with interested parties for publishing your streams to Red5. This covers all the drones and IP cameras that I’ve had exposure to over the years that do not already have a means to egress via RTMP. While Flash Player is “dead,” RTMP as a protocol certainly is not.

Using GStreamer for Stream Processing

First up is to download the GStreamer application, a powerful multimedia framework that can handle the conversion and streaming process. To learn more about it, read our previous blog on using GStreamer for low-latency streaming.

Discovering Your Stream Format

If you don’t know the format of the video and/or audio (if present) on your drone, the discoverer application can be used to see what you’re working with:

gst-discoverer-1.0 rtsp://10.0.0.10:554/stream

Replace 10.0.0.10:554 in the RTSP stream URL with your drone or camera IP address and port.

Video-Only Streams

When the source only provides video, this is the pipeline you’d use (assuming H.264):

gst-launch-1.0 rtspsrc location="rtsp://10.0.0.10:554/stream" latency=0 name=rtsp ! rtph264depay ! h264parse ! video/x-h264 ! queue ! flvmux name=mux ! rtmpsink location="rtmp://10.0.0.35:1935/live/drone1 live=1"

Audio-Only Streams

If the source is just audio, use this pipeline assuming an AAC codec:

gst-launch-1.0 rtspsrc location="rtsp://10.0.0.221:554/stream" latency=0 name=rtsp ! rtpmp4gdepay ! aacparse ! audio/mpeg ! queue ! flvmux name=mux ! rtmpsink location="rtmp://10.0.0.35:1935/live/remotemic1 live=1"

Combined Audio and Video Streams

Finally, for sources providing both audio and video:

gst-launch-1.0 -v rtspsrc location="rtsp://10.0.0.10:554/stream" latency=0 name=rtsp rtsp. ! rtph264depay ! h264parse ! video/x-h264 ! queue ! mux.video rtsp. ! rtpmp4gdepay ! aacparse ! audio/mpeg ! queue ! mux.audio flvmux name=mux ! rtmpsink location="rtmp://10.0.0.35:1935/live/audvid1 live=1"

Alternative: Red5 Restream API

This example demonstrates the simplest means to get your source devices providing egress via RTSP into Red5 without RTMP, using the Red5 Restream API via curl:

curl -X POST http://10.0.0.35:5080/live/restream \
  -H "Content-Type: application/json" \
  -d '{
    "guid":"live/audvid1",
    "context":"live",
    "name":"audvid1",
    "level":0,
    "parameters":{
      "type":"ipcam",
      "action":"create",
      "remoteContextPath":"stream",
      "remoteStreamName":"",
      "host":"10.0.0.10",
      "port":554
    }
  }'

Final Notes

These examples use a non-routable network, and you can change the fields to fit your devices and environment. For more detailed information and advanced configurations, see our documentation. Whether you’re working with consumer drones, professional camera equipment, or IP security cameras, these methods should help you get your RTSP streams flowing into Red5 for further distribution and processing.

Join the Red5 MOQ Beta to Test Streaming with Your Application

Maria Artamonova — Mon, 20 Apr 2026 15:08:23 +0000

The Red5 MOQ beta gives you early access to one of the first production-ready Media over QUIC streaming solutions at global scale. In this post, we explain what the beta includes, how it works, and how you can get access. You will also learn what to expect during onboarding and how to start testing with your own application.

About Red5 MOQ beta

Red5 Cloud MOQ beta is one of the first end-to-end production-ready MOQ streaming solutions that operates at global scale. In addition to supporting multiple ingest protocols such as WHIP, SRT, RTMP, and Zixi, delivering across CacheFly’s global network, and providing our MOQ-based player, it makes it easy to deploy real-time streaming without managing infrastructure, scaling, monitoring, or performance optimization. This solution gives organizations and businesses a complete, flexible, fully managed architecture they can use today without being locked into a single protocol.

Red5 MOQ beta with CacheFly CDN deployment diagram.

If you are attending the NAB Show, you can visit the CacheFly booth W3129 to see how this works in practice and speak with our team in person.

How to Get Beta Access

Since the Red5 MOQ beta is not publicly available yet, we grant access individually to make sure each setup is aligned with your use case.

Here’s how to get started:

Reach out to us using this link.
Meet with our sales team to discuss your use case and confirm eligibility for the beta. Access is limited to selected teams with large-scale use cases (not solo practitioners). The beta runs for 30 days by default, with extensions available if your testing requires more time.
Meet with our technical team to configure your beta access and get guidance on how to get started.

This process ensures you can test the Red5 MOQ beta in a way that reflects your real-world requirements and get the most value from early access.

Live Streaming From Space: The Infrastructure Challenges Behind Live Video Beyond Earth

Maria Artamonova — Mon, 13 Apr 2026 18:28:31 +0000

Space, the final frontier in live video streaming. Today I want to discuss what it takes to deliver reliable live streaming from space, from early orbital broadcasts to upcoming lunar missions and beyond. We will break down the technical, operational, and viewer experience challenges behind delivering a live feed from space at scale.

From the Moon to Millions: NASA’s Streaming Vision

Back in December I had the privilege of attending a super cool presentation at the SVG Summit 2025, Live Streaming from the Moon: From Sports to Space with NASA+ with Lee Erikson and Rebecca Sirmons. What they covered sounded a bit like sci-fi fiction, but they made it clear plans are in the works for a massive live streaming event from space.

From the talk I learned that NASA is opening up their live feed for anyone and everyone who wants to use it to create their own live viewing experiences. I think the possibilities of this are super exciting, meaning we can create some really unique experiences with their live content. Imagine synchronized viewing rooms where millions of people watch a lunar landing together with real-time telemetry overlays, mission data, and social interaction aligned to the exact video moment.

You might be wondering why NASA was presenting at a Sports Video conference, since obviously space travel isn’t a sport. Rebecca and Lee made it clear that the problems they face in broadcasting their live event has many of the same challenges that sports broadcasters do. Therefore they came to the conference to get our (us in the live sports business) feedback.

Artemis II Mission: What Viewers Expect vs Reality

Artemis II marked NASA’s next major step toward returning humans to deep space, with a crewed mission that served as a dress rehearsal before future lunar landings. The mission included a full launch sequence, rollout of the rocket, a multi-day journey around the Moon, and a safe return to Earth, validating systems that will support long-duration human spaceflight beyond low Earth orbit.

From a viewer experience perspective, the video delivery can be divided into three stages: the launch phase with the crew departing Earth and reaching orbit, the live video from space during the translunar flight, and the return to Earth with reentry and splashdown. The Artemis II launch was scheduled for April 1, 2026, at 6:24 PM ET and could be viewed as a live feed on NASA+, the NASA YouTube channel, and via the NASA App. Coverage was also available on TV through major networks like CBS and CNN, and via streaming platforms such as Amazon Prime, Roku, and FOX Weather. A recording of the broadcast is also available for replay.

The expectations for the launch broadcast were massive, especially given how modern audiences consume live video, and how commercial space companies have pushed expectations higher. Audiences now expect cinematic quality from launches because companies like SpaceX normalized multi-camera live production with real-time telemetry overlays.

Looking at viewer feedback from Reddit and engineering communities criticized Artemis coverage for inconsistent production quality and long stretches of filler content:

Viewers were disappointed with the production quality during both the launch and reentry phases. Feedback highlighted issues such as manual camera tracking of the rocket that appeared slow and often out of focus, excessive cuts to crowd reactions instead of showing the mission itself, missed key moments like SRB separation, limited onboard camera footage, and low-quality visuals including oversaturated Orion camera feeds and lagging CG representations.
Multiple users pointed out that feeds dropped or went black at crucial moments, including right before and during liftoff. This created confusion about whether issues were technical failures or production errors.
Many criticized the broadcast pacing, especially during the countdown and pre-launch segments where engagement dropped due to lack of meaningful visuals or data overlays.
Viewers were frustrated with delays between events and what was shown in the live stream. Several users pointed out noticeable lag in the live feed compared to real-time expectations.

Overall, the expectation was clear. Audiences wanted a true live experience with synchronized data, minimal delay, and a compelling broadcast that felt modern. Today, people expect high-quality video similar to what they see in video on demand replays of live broadcasts, even when the live video is coming from space. This has become the standard expectation for all live content, regardless of where it originates. However, live streaming, especially from space, is fundamentally different from streaming on Earth. It introduces a set of unique challenges that I will explain next.

Engineering Reality: Streaming Beyond Earth

Historically, live video from orbit has already proven technically feasible. Systems like the ISS High Definition Earth Viewing cameras streamed live footage from space using commercial camera hardware, showing that consumer-grade technology can operate in orbit with proper engineering.

SpaceX regularly live streams from low orbit in their rocket launches with multi-camera setups, onboard live video feeds, and real-time telemetry overlays that deliver a polished broadcast experience to viewers on Earth.

However, future lunar missions introduce a different scale of challenge compared to low Earth orbit. Latency increases dramatically due to distance, transmission windows are constrained, and relay satellites become part of the architecture. Bandwidth is limited because astronaut safety data always has priority. Hardware has to survive radiation and extreme environments. Certification cycles can take years, so systems often launch with technology that is already a decade old. That changes assumptions about synchronization and interactivity.

One of the biggest architectural differences compared to terrestrial streaming is that space video systems must operate in intermittently connected environments. Unlike Earth networks where persistent connectivity is assumed, spacecraft often rely on scheduled transmission windows through relay satellites. That means buffering strategies, forward error correction, and delay-tolerant networking concepts become part of the video delivery stack. In many cases, reliability matters more than immediacy, which forces engineers to rethink traditional assumptions about latency optimization.

To overcome those limitations, the industry is starting to explore entirely different transmission technologies. Another emerging factor is optical communications. Space agencies are investing heavily in laser-based transmission systems to increase bandwidth between spacecraft and Earth. We at Red5 hold two patents related to extraterrestrial streaming. The core idea involves transmitting video over long-distance optical links such as line-of-sight laser communication instead of traditional radio frequencies. This approach can significantly increase bandwidth efficiency by a huge amount while reducing interference, which becomes critical when you are dealing with massive distances and constrained transmission windows.

Another interesting challenge is compression efficiency. When line of site laser transmission is blocked and bandwidth is scarce, or other circumstances cause transmission to be limited, every bit matters. Advances in codecs, adaptive bitrate strategies, and edge processing will play a major role in making high-quality video feasible beyond Earth orbit. There is also growing interest in performing AI-assisted processing at the edge, for example prioritizing regions of interest or dynamically adjusting quality based on mission context before transmission.

To make matters even more difficult is the speed of light limitations and transmitting at tremendous distances. A transmission from Mars for example takes on average around 40 seconds, so real-time communication isn’t possible. This exact scenario was the fodder for last year’s April Fool’s joke, where we claimed to create negative latency streaming that indeed would have made real-time communication to and from Mars possible. You’d be surprised at how many people actually wanted access to that beta.

Conclusion

Live streaming from space has been technically feasible for years, but Artemis II showed how today’s NASA live streaming infrastructure actually performs at scale. While the experience did not always meet viewer expectations due to delays and production limitations, it is important to recognize that streaming from space operates under fundamentally different constraints than terrestrial live streaming.

At the same time, many aspects of launch broadcast production from Earth can already be improved using modern tooling. AI-powered features such as automated object tracking for rocket launches, real-time transcription and translation, and moderation of user-generated content based on predefined rules can significantly enhance the viewing experience. Engagement can also be improved with chat overlays powered by real-time data streaming, as well as tighter synchronization of telemetry data, rocket trajectory, and weather conditions with live video.

As extraterrestrial streaming evolves, combining these production advancements with space-grade infrastructure will help close the gap between what is technically possible and what audiences expect from a modern live broadcast from space.

Ad Insertion for MOQ (Media over QUIC): What Is Possible Today and What Comes Next

Maria Artamonova — Thu, 02 Apr 2026 13:21:26 +0000

To continue my coverage of all things MOQ, today I want to touch on something that keeps coming up in MOQ discussions: ad insertion.

Ultra-low latency delivery is only part of the equation. For MOQ to be viable in real production environments, monetization has to work too. That means clean ad signaling, measurable delivery, and architectures that scale without breaking synchronization.

IETF MOQ interim at Google’s Boulder campus

This was one of the topics at the recent IETF MOQ interim at Google’s Boulder campus in February 2026. Watch the video below, where I discuss this event with my teammate Paul Gregoire, Red5 Solutions Architect, who attended it.

To better understand how these concepts apply in practice, here are the key definitions used in ad insertion workflows for MOQ:

Server-Side Ad Insertion (SSAI): ads are stitched directly into the video stream on the server before the stream is delivered to viewers.
Server-Guided Ad Insertion (SGAI): the server signals ad opportunities and decides when and which ads to request and play.
Client-Side Ad Insertion (CSAI): the video player on the viewer’s device requests, loads, and inserts ads during playback instead of receiving a prestitched stream.
Regional blackout: a restriction that blocks or replaces live content for viewers in certain geographic areas due to licensing or local broadcast rights.

Gwendal Simon from Synamedia and Will Law from Akamai Technologies presented how MOQ and the MOQ Transport Streaming Format (MSF) can carry SCTE-35 signaling for Server-Guided Ad Insertion (SGAI) as well as other control scenarios such as regional blackout enforcement.

Figuring out how content works with advertising and blackout use cases in a MOQ environment is critical for the technology to support real-world media and entertainment applications. Because of that, the topic is receiving significant attention across the MOQ community. The problem is not fully solved yet, but progress is moving quickly as new approaches and demonstrations continue to emerge.

Gwendal and Will presented what is possible today: a working architecture where ad decisioning systems publish SCTE-35 signaling as structured events on a dedicated Event Timeline track, while media and advertising streams remain separate and independently distributed over MOQ. Subscribers can follow these signals in real-time to switch between media and ad tracks, fetch ad content dynamically using identifiers such as MOQ URLs, and return to the primary program stream at the correct playback moment.

Learn more from the files they presented at the event.

Ad Insertion in MOQ — Interim Meeting Boulder Download

SGAI Over MOQ_ SCTE35-Based Event Timeline Type Definition Download

The approach demonstrates how existing broadcast signaling models can operate over MOQ without embedding cues directly inside the video stream, allowing signaling and media delivery to scale independently while preserving the timing relationships needed for live playback.

Does Red5 Support Ad Insertion for MOQ?

We are actively working on this area with partners like Showfer Media, integrating ad workflows into real-time streaming pipelines so MOQ can move from experimental to production-ready systems. If you are interested in learning more, visit us at the NAB Show 2026, where we will showcase MOQ and TrueTime Solutions™ in action at the Nomad Media booth W2357 and AWS booth W1701. Reach out to us here to schedule a meeting at NAB. Our schedule is filling up quickly, so it is best to plan ahead.

Become a Beta Tester of MOQ Streaming Powered by Red5 and CacheFly

Beyond the live demos, we will introduce how Red5 Cloud will deliver MOQ at scale through our partnership with CacheFly. In this workflow, live streams are ingested into Red5, processed through our video packaging layer, and delivered via CacheFly using either MOQ or HTTP-based protocols like HLS and LL-HLS. This gives customers flexibility. You can deliver ultra-low latency streams with MOQ where real-time performance matters most, while still supporting traditional formats for broader device compatibility. It is not about replacing one protocol with another. It is about choosing what works best for your use case.

Our teams will be collecting beta testers at NAB for our globally deployed MOQ network. It allows Red5 Cloud users to leverage CacheFly CDN for MOQ delivery. If you want in on this early or just want some more details on how it might work for your business, reach out to us using this link.

Conclusion

Ad insertion for MOQ is evolving quickly as the industry works to make real-time streaming monetizable without sacrificing synchronization or scale. While approaches like SCTE-35–based signaling and SGAI over MOQ already show strong potential, the ecosystem is still maturing as partners continue building production-ready workflows. With ongoing collaboration and real-world testing, MOQ is moving closer to supporting reliable, scalable ad-supported streaming. For a deeper look at how MOQ compares to existing transport approaches, read our “SRT vs MOQT” blog.

Red5 TrueTime Meetings™ for News: From the Field to Broadcast in Real-Time

Maria Artamonova — Tue, 24 Mar 2026 13:40:29 +0000

Today I want to talk about how news organizations can bring remote reporters, field video, and user-generated content into live production workflows without losing quality or control using Red5 TrueTime Meetings™.

Why Zoom, Facetime, Or Teams Do Not Work Well For News Organizations?

Traditional meeting tools like Zoom, Facetime, and Teams were never built for broadcast. They are closed systems with limited control over routing, monitoring, and integration. News teams often end up stitching together multiple tools just to get someone on air.

There are also concerns about outages and centralized service failures. In April 2025, a global Zoom outage generated tens of thousands of user complaints and disrupted operations for organizations that rely on it for daily communication. For live news production, even a short outage can mean losing a critical moment on air.

How Red5 TrueTime Meetings™ Can Help Evolve News Broadcasting?

This is where our open source TrueTime Meetings™ becomes interesting. Watch the video below to learn more about this solution.

Red5 TrueTime Meetings™ runs on Red5 live streaming infrastructure, so participants who join through a simple browser link are not just “meeting attendees.” Their streams can function as production-ready inputs that can be routed, recorded, monitored, or integrated into newsroom workflows.

Perhaps more importantly, as an open source project, TrueTime Meetings™ was designed for developers to take the parts of the code that they need and apply them to their own applications.

For news environments, that enables several practical scenarios:

Remote reporters joining live from the field through a browser or mobile device.
Citizen journalists contributing video during breaking news events.
Guest interviews without relying on consumer conferencing platforms.
Distributed newsroom coordination across locations.
Pre-production green rooms before going live.

What makes this even more powerful is how it works alongside contribution workflows with partners like Zixi. Zixi is widely used in broadcast environments for reliable contribution and transport over IP. When combined with Red5, news organizations can monitor high-fidelity contribution feeds with end-to-end latencies under 250ms while also enabling browser-based contributors through Red5 TrueTime Meetings™. That means professional camera feeds, bonded cellular transmitters, and user-generated streams can all land in the same production environment.

The integration also enables capabilities that matter directly to news operations:

Real-time monitoring of contribution feeds with high signal integrity.
Syndicating multiple live sources into multiview layouts for production teams.
Commercial slating and content replacement during live workflows.
Secure ingestion and rebroadcast of user-contributed streams.
Lower operational costs compared to traditional satellite or fiber workflows.

One example that stands out is breaking news coverage. A newsroom can receive professional camera feeds through contribution infrastructure while simultaneously bringing in eyewitness footage from smartphones through Red5 TrueTime Meetings™. Both sources remain synchronized and production-ready.

Another important factor is deployment flexibility. Red5 TrueTime Meetings™ can run in Red5 Cloud for rapid deployment or on-premises with Red5 Pro when security, compliance, or infrastructure control are required. And of course, it’s open source, which allows broadcasters to customize branding and workflows instead of forcing teams into generic meeting interfaces.

Try Red5 TrueTime Meetings™ today

Option 1:

Download the source from GitHub

Get the open source code, customize the front end, and deploy in your own environment. This is the best path if you want full control and deeper product integration.

View on GitHub >

Option 2:

Launch it in Red5 Cloud

Get the open source code, customize the front end, and deploy in your own environment. This is the best path if you want full control and deeper product integration.

Option 3:

Deploy with Red5 Pro

Prefer a self-managed setup? Red5 Pro users can download the source and deploy TrueTime Meetings™ in their own infrastructure, then extend it for their application and workflow needs.

Schedule a consultation >

What I find most compelling is how convenient it is and how seamlessly it integrates into existing workflows and consumer applications. That is what really accelerates getting new content into the news cycle.

When reporters, guests, and contributors can join a live broadcast in seconds instead of minutes, response time improves. In news, that speed often translates directly into audience engagement and competitive differentiation.

Conclusion

Red5 TrueTime Meetings™ helps news organizations bring remote contributors into live production workflows without sacrificing quality, speed, or operational control. Instead of relying on consumer meeting platforms, broadcasters can use Red5 TrueTime Meetings™ to ingest browser-based video as production-ready inputs that integrate directly into newsroom infrastructure. This approach allows news teams to move faster, capture breaking moments, and deliver live coverage with professional broadcast reliability.

SS4A Grant: Proven Video Streaming Infrastructure for Safer Road Initiatives

Maria Artamonova — Wed, 18 Mar 2026 19:36:59 +0000

SS4A grant conversations have been coming up a lot lately in discussions I’ve had with teams that have either applied for or already received funding. What stands out to me is how much opportunity there is to modernize road safety using video streaming infrastructure and real-time intelligence. Today, it is no longer enough to rely on passive monitoring. In this article, I’ll explain how the SS4A Grant Program works, what technology is required, and how Red5’s real-time intelligence can transform traffic monitoring capabilities, video surveillance, and vehicle monitoring.

About Safe Streets and Roads for All (SS4A) Grant Program

The SS4A Grant Program is a federal initiative led by the U.S. Department of Transportation (DOT) that helps communities reduce roadway fatalities through a system approach to safety. It funds planning, infrastructure, and operational improvements that make streets safer for all users.

At its core, SS4A supports data-driven safety strategies. Communities use funding to build action plans, deploy infrastructure, and implement technologies that improve outcomes across traffic and vehicle monitoring, and video surveillance systems. The goal is not just collecting more data but enabling real-time intelligence that helps agencies act faster and prevent incidents before they escalate.

To apply for SS4A funding, organizations must carefully review the NOFO, the Notice of Funding Opportunity. This document outlines all requirements, eligibility criteria, deadlines, and instructions needed to submit a competitive application. It is not optional reading. It is effectively the checklist that determines whether your application will be considered.

The NOFO explains two main grant types: Planning and Demonstration Grants and Implementation Grants. Planning and Demonstration Grants focus on developing or updating an action plan, running pilot programs, and testing strategies. Implementation grants fund actual deployment of projects identified in an approved action plan. Applicants must choose one path per application and must meet strict requirements. These include developing a comprehensive action plan with defined components such as safety analysis, stakeholder engagement, strategy selection, and measurable outcomes.

Your application must include detailed documentation, including a plan template, supporting materials, and a clear description of how your project aligns with SS4A priorities. Deadlines are fixed and must be followed precisely.

What Do You Need From A Technology Standpoint

Most cities today already have cameras, sensors, speed cameras, drones, and connected intersections generating massive amounts of data. The issue is not data collection. It is that today’s traffic monitoring systems are delayed, siloed, difficult to scale across districts and departments, and rarely actionable in real time. On top of that, they often lack advanced AI and vision-language model analysis of live camera feeds that could automatically surface risks, detect patterns, and turn raw video into meaningful operational insight. What cities actually need is real-time roadway intelligence. That gap is exactly where modern streaming infrastructure can make a difference.

Modern SS4A projects require video streaming infrastructure that can ingest live feeds from video surveillance systems, drone operations, and mobile devices without replacing existing infrastructure. Video must be processed in real-time, apply AI models, and deliver insights instantly.

With the right approach, agencies can detect license plates, identify anomalies, and generate real-time threat intelligence from live feeds. Instead of reviewing footage after an incident, teams can act while events are unfolding.

This shift enables:

Faster detection of accidents, congestion, and risks involving vulnerable road users.
Real-time intelligence across departments using shared live video.
Better coordination between emergency responders and traffic operators.
Scalable vehicle monitoring across jurisdictions.

Without this foundation, SS4A-funded projects risk becoming another layer of disconnected systems rather than a unified safety solution.

How Red5 Can Help

We provide video streaming infrastructure designed for real-time intelligence at scale. The platform ingests video from traffic cameras, drones, or even mobile devices, ingest it using standard protocols without replacing existing infrastructure, process it in the cloud with AI (for detecting and alerting anomalies), and deliver sub-second live video to operators and agencies that need to act immediately.

When you move from delayed analytics to live situational awareness, several things change:

Risks can be detected sooner, including identifying accidents, congestion, wildfire events, dangerous intersections, or vulnerable road users.
Emergency response coordination improves because everyone sees the same live view, helps identify stolen vehicles in real-time, and enables faster incident verification before dispatch.
Cross-agency collaboration becomes practical instead of theoretical.
Safety outcomes can actually be measured for programs like the U.S. Department of Transportation’s Safe Streets and Roads for All initiative..

One thing that stands out about Red5’s approach is that it does not require ripping out existing infrastructure. Cities can use cameras they already have and turn it into something operationally meaningful.

Our Customers Success Stories

We have seen this in real-world deployments.

For example, Red5 supported a real-time drone streaming solution for the San Diego County Sheriff’s Department, enabling faster response during critical incidents.

In another case, Red5 worked with Nomad Media to power a traffic monitoring solution for Caltrans District 7, where sub-250ms latency video improves decision-making during fires, disasters, and large-scale incidents. We provide a unified interface for viewing and sharing live and recorded roadway video across agencies including the California Highway Patrol. Faster visibility leads to faster decisions, and faster decisions save lives.

Conclusion

SS4A Grant initiatives are pushing cities to rethink how they use data, moving from passive monitoring to real-time intelligence powered by video streaming infrastructure. Today, the gap between data collection and action is the biggest challenge in road safety. By adopting modern traffic monitoring software, video surveillance, and vehicle monitoring solutions, agencies can turn SS4A funding into measurable safety outcomes. If your organization has applied for or received SS4A funding, feel free to reach out to us.

What Can Real-Time In-Stadium Streaming Do for Live Sports Broadcasting and Event Production in 2026?

Maria Artamonova — Mon, 16 Mar 2026 18:00:30 +0000

There’s a quiet revolution happening in stadiums and arenas. And it’s not just about 5G or giant LED screens. It’s about real-time video, interactive features, and creating unforgettable in-venue experiences that extend far beyond the walls of the stadium. In this study, you’ll learn what in-stadium streaming can do for live sports broadcasting and event production in large venues, why it is becoming a game-changer for both fans and businesses, and what innovative solutions Red5 and partners provide.

What Is In-Stadium Streaming?

At Red5, we’ve been working on revolutionizing stadium experiences with the following partners.

Together, Red5 Pro‘s real-time streaming server software and Amino’s media players and device management capabilities power on-premise streaming for large-scale venues like stadiums. We are currently working on a large-scale pilot with a customer in Mexico that uses this setup to stream live sports to TVs across stadiums with synchronized, low-latency video on 15–20 screens in view. It scales to thousands of endpoints without heavy infrastructure, while reducing operational costs.
The Famous Group, on the other hand, is flipping the camera around by streaming fan content from phones directly to those same digital signs in real time. Think live shoutouts, dance cams, and on-the-fly interactions that make the crowd part of the show.
Another exciting partnership we’re working on is combining on-prem deployment with Osprey encoders. With frame-level encoding they provide and Red5 deployed on a server on-site, we’ve seen glass to glass latencies as low as 60ms. That aligns (or often beats) with the speed of sound depending on where you are situated in the stadium. So the video on the screen matches what your ears hear, which has been sorely missing at concerts and games alike. This is particularly important with live concerts and getting lip-sync dialed in on the video playback with the sound in the arena.

What AI-Powered Capabilities Red5 Delivers

Here are some of the AI-powered capabilities Red5 delivers for enhancing sports and event in-stadium streaming experiences.

Frame-level detection: Extracting video frames in under a second and handing them off to AI models. This makes it possible to flag large crowd gatherings and enable routing at mass events to ensure safety, track player movements in real time, and detect unauthorized access to restricted areas in a stadium.
Audio intelligence: Using models like NVIDIA’s Parakeet for live transcription, translation, and generating searchable metadata from conversations or broadcasts. Imagine live sports commentators’ play-by-play calls being instantly transcribed and translated, or concert lyrics synced in real time for fans across multiple languages.
Smart search: Generate searchable metadata from video or audio content and automatically tag key events, such as goals and penalties in sports, so they can be quickly located in the recording.
Custom advertising: Align ads with the tone of the content to ensure higher relevancy and conversion rates. For example, you could display a sportswear commercial right after a major goal replay, or showcase upcoming tour dates immediately following a concert highlight.

How These Solutions Benefit Both Fans and Businesses

What excites me most about real-time stadium streaming is the value it unlocks for businesses:

Enhance fan engagement with multi-view angles that let attendees follow the game their way.
Expand your audience and drive customer loyalty by adding new high-value capabilities. Deliver broadcast-quality video and perfectly synced audio with the live action. Offer personalized in-app audio with selectable commentators and languages.
Monetize and earn more revenue through interactive overlays and targeted ads tailored to each fan’s location and profile.
Reduce infrastructure costs by deploying on prem, on your own cloud account, or using Red5 Cloud’s Pay-As-You-Grow service.

While sports and music use cases are some of the most obvious, fan festivals, amusement parks, eSports events, and other use cases could benefit from this kind of infrastructure. And here’s where it gets even more exciting: this isn’t just for the world’s most connected stadiums.

In many emerging markets, connectivity inside venues still lags far behind. Public internet can be slow or unreliable, and building centralized infrastructure often feels out of reach. But it does not have to be. By deploying Red5 on-prem, paired with private 5G or dedicated Wi-Fi networks, venues can bypass the limitations of external connectivity altogether. You get the benefits of real-time streaming, synchronized playback, and interactive experiences, all running locally on your own hardware.

This approach is already proving effective in places like Mexico, where teams are using this model to deliver broadcast-quality experiences without needing massive cloud infrastructure or robust public internet access. It’s a way for stadiums in under-connected regions to leap ahead, not wait to catch up.

Conclusion

It feels like the time is finally right, the networks are ready, and the tech is here for stadiums. And the demand for immersive, interactive, real-time experiences is only growing.

In-stadium streaming is redefining how fans experience live events and how venues unlock new revenue opportunities. From synchronized, ultra-low latency video to interactive tools like kiss cams and fan shoutouts, the technology enhances engagement while lowering infrastructure costs. Whether in the world’s most connected arenas or in emerging markets, Red5 and its partners are proving that the future of live event broadcasting is already here.

TrueTime Meetings™: Open Source Video Calling Built for Real-Time Streaming

Maria Artamonova — Fri, 13 Mar 2026 13:50:57 +0000

The world has reached a turning point in internet video engagement where the ubiquitous need for instant access to interactive audio/video communications can’t be satisfied by the usual approaches to video conferencing.

Good as they might be at supporting traditional video conferencing, and even there they leave a lot to be desired, the likes of Google Meet, Zoom, Microsoft Teams, Cisco Webex , etc. fall far short of what’s required as a new era in live video streaming takes hold. To put it bluntly, they’re simply not designed to accommodate a world where spontaneous face-to-face social engagement is becoming an intrinsic component of live streaming across the consumer, enterprise and institutional landscapes. See our latest white paper for an examination of the major trends driving the need for a new video communications paradigm.

Of course, the more ubiquitous demand for infrastructure supporting such capabilities becomes, the more needs to be done to ensure that demand is met. Which is why, along with platforms like Red5’s Experience Delivery Network (XDN) Architecture that heavily rely on WebRTC and its enhancements for current transport needs, there’s an industry-wide standard informally known as MOQ nearing competition under the guidance of the Internet Engineering Task Force. With widescale industry engagement including full support from Red5, MOQ is set to drive faster emergence of a global marketplace connected by real-time interactive streaming.

As next-gen streaming infrastructures take hold, it’s clear that from now on the live mass market streaming and video calling components must act as a single piece as opposed to remaining locked into the bifurcation that currently persists. This requires a video meeting platform built on global real-time streaming architecture that can support point-and-click activation of fully synchronized unscheduled interactive A/V communications in any use case reaching any number of users at 250ms or lower end-to-end latencies.

We at Red5 met this challenge by introducing a set of open-source software modules comprising the TrueTime Meetings™ toolset. Now service and applications providers can make A/V communications an intrinsic, readily accessible part of live streaming UX at these performance levels in virtually any scenario.

The options start with TrueTime Meetings™ default parameters supporting a more scalable, higher quality version of a conventional conferencing solution, with or without appointment requirements. Out of the box, TrueTime Meetings™ is more or less a Google Meet clone in terms of functionality with features like live transcriptions, save recordings, virtual background replacement, and more. Those looking to customize a solution to meet their goals can leverage the flexibility of this open source software stack to implement whatever approaches to real-time A/V communications fit their use cases. Relying on in-house and/or Red5 development teams, they can create their own ground-breaking communications environments from a deep well of open-sourced TrueTime Meetings™ functionalities together with any of the tools available with other TrueTime solutions.

TrueTime Meetings™ tools are available like the other Red5 TrueTime toolsets at no added costs beyond the usage-based pricing that makes the Red5 Cloud managed platform-as-a-service (PaaS) and the self-managed Red5 Pro implementations of the company’s Experience Delivery Network (XDN) Architecture a cost-effective approach to real-time interactive streaming. In addition, Red5 customers have access to major advancements that are shaping the next generation in interactive video communications. These include support for:

AI-assisted Large Language Model (LLM) applications ranging from real-time analytics and voice-to-text and text-to-voice language translation to execution of the creative capabilities driven by AI Vision Language Models (VLMs).
A/V connectivity with use of HEVC and, soon, AV1 to attain 4K quality levels and beyond;
Spatially realistic audio and video experiences with immersive tie-ins to extended reality (XR) applications.

The Unique Capabilities of the TrueTime Meetings™ Platform

With TrueTime Meetings™ we’re addressing the need for a video meetings platform with global reach that can be easily configured to accommodate the vast range of socialization strategies that are becoming more and more expected in modern live video streaming experiences.

While the need for capabilities akin to what’s available from conventional video conferencing platforms will persist, a rapidly expanding share of the interactive video communications strategies coming into play require what’s not available from the conventional platforms, including:

adaptability to any strategy,
unlimited scalability,
ease of use supporting instantaneous appointment-free participation,
A/V quality levels matched to current expectations, and
support for the new technologies reshaping the communications landscape, from AI to innovations like LiDAR, spatial audio and the many permutations of AR and VR.

For the first time, we have made it possible to meet all these requirements with the freedom and cost benefits that come with using the open-source frontend code base underlying the tools and SDKs comprising TrueTime Meetings™. The license-free possibilities range from a default mode that adds unlimited scalability and high A/V quality for users requiring a conventional video conferencing platform to easily structured combinations of TrueTime Meetings™ elements in support of any use case.

Critically, the tools and functionalities comprising TrueTime Meetings™ don’t entail any kind of forklift departure from the fundamental capabilities that have long characterized XDN Architecture as a foundation for real-time interactive streaming. Abundant documentation on our website describes the full range of XDN capabilities that go into enabling real-time streaming in any direction from any number of originating sources to any number of receivers with end-to-end latencies at or below 250ms over any distance. See, for example, these blogs on the keys to the XDN performance advantage over all other real-time streaming platforms, the role Red5 is playing supporting distributed collaboration in live production, and the capabilities achieved in collaboration with Red5 partners whose solutions have been integrated to work with XDN Architecture.

Mirroring the convenience that comes with building apps using our other toolsets, including the TrueTime MultiView™, Watch Party™, Studio™ and DataSync™ toolsets Red5 created to facilitate building specific applications on XDN infrastructures, TrueTime Meetings™ consists of a stack of open-source software tools with easy-to-follow guidance on how to use them on a customer portal, ensuring enough functionalities are embodied in the stack to take video communications anywhere a customer wants to go.

All TrueTime Solutions™ are available to XDN customers at no extra costs, which in the case of TrueTime Meetings™ applies whether customers choose to utilize the tools as structured in the feature-rich video conferencing default mode or to use them to build interactive communications systems precisely tailored to their use cases. Red5 Cloud customers can customize their uses with their own branding through direct access to Meetings in the TrueTime Apps section on their Red5 Cloud dashboards.

For those deploying in their own environments, Red5 Pro customers can put TrueTime Meetings™ to use by downloading whatever tools they need from the TrueTime apps repository.

In all cases, customized usage is facilitated through the Red5 Pro Conference SDK, which provides a high-level API for building video calling applications while abstracting the complexities of WebRTC management, media handling, and connection management. Settings applied with custom builds can be modified, added or deleted without requiring a full application rebuild.

Red5 Pro users can launch real-time streaming with customized applications enabled by TrueTime toolsets, including Meetings, using the free Java-coded Red5 Media Server with its simple plugin architecture, which has been installed by the likes of Amazon, the U.S. Department of Defense, Akamai, Harvard University and many other entities in over one million instances of XDN usage worldwide. Or they can use their own server software to accomplish the same things.

Red5 Cloud and Red5 Pro customers can integrate into their existing workflows the pre-packaged TrueTime Meetings™ tools comprising the default video calling mode or they can integrate whichever tools they need to build their own custom calling applications. This helps to ensure that whatever approaches they take, the calling functions work in holistic alignment with their real-time streaming operations.

TrueTime Meetings™ users also benefit from our latest support for AI.

AI-assisted multilingual speech-to-text captioning and large language model (LLM) multilingual generation of speech from text are included in the TrueTimes MeetingsTM default mode with the Red5 Cloud and Red5 Pro Enterprise subscription tiers. They are also available on a per-user negotiated cost or no-cost basis with the Red5 Cloud Pay-as-You-Grow and Growth plans and the Red5 Pro Developer Pro, Start-Up and Growth Pro plans.

More broadly, use of TrueTime Meetings™ is enhanced by virtue of Red5’s integration of XDN Architecture with an ever-expanding array of LLMs and VLMs, which are available to work with any Meeting use case. At the same time, customers can arrange for integration of any other AI models that employ open interfaces compatible with the industry standards used with Red5 APIs.

Adding to the AI functionalities available to TrueTime Meetings™ users, for the first time anywhere we’re enabling virtually instant extraction of A/V frames at any frequency down to sub-second intervals from content delivered to Red5 Cloud infrastructure over any supported ingest, including WebRTC / WHIP, SRT, Zixi, RTMP, and RTSP. This is vital to thorough analysis of payloads in surveillance operations and in any other real-time streaming scenarios involving granular enhancements to metadata, avoiding unwanted content elements and monitoring user behavior.

TrueTime Meetings™ Video Calling Default Mode

For customers who simply want to be able to support a better version of conventional video conferencing systems, the TrueTime Meetings™ default mode is easily activated by responding to prompts on their dashboards. The automated video calling setup creates an easy-to-manage conferencing adjunct to any streaming scenario.

The platform can be used as a standalone center for appointment-based group meetings or as a video communications overlay integrated for access as an appointment-free component of the customer’s real-time streaming UX. TrueTime Meetings™ can also be activated with a seamless transfer from an HTTP-streamed live sports or other event to real-time XDN streaming to support viewer participation in video conversations during post-event programming.

Whatever approach is taken in the use of XDN Architecture, TrueTime Meetings™ allows viewers, remote commentators or any other category of collaborators and participants to be brought into video conversations associated with webinars, trade shows. live sports and newscasts, esports competitions, game shows, live-shopping programs – the list is endless. And the platform can be used in audio-only group meeting applications as in the case of live-streamed talk radio programs and audio podcasts.

Some of the features included with the core default video conferencing mode include:

Scalability – Multiuser participation with up to 30 on-screen users at any one time with managed access available to any number of others extending into the millions as Meetings users are rotated in and out of a given streaming session.
Participation Monitoring in Appointment-Free Applications – Conferencing managers’ ability to track what’s happening on the platform is facilitated by automated participant updates when users enter or leave a session and by signals that let organizers know when someone turns a camera on or off or mutes or unmutes a microphone.
Video Quality Control – The H.264 default encoding used with TrueTime MeetingsTM can support any level of screen resolution through management of the bandwidth allocated to the A/V streams. Whereas conventional conferencing platforms typically top out at 720p with some charging premium fees to enable HD 1080p, display resolutions in TrueTime Meetings™ sessions can surge to 1080p HD and beyond based on whatever bandwidth is made available by session managers. Side-by-side comparisons with conventional streaming show that at any given bandwidth allocation, image clarity in the Meetings display windows is much greater than the alternative. Moreover, the quality is persistent with the real-time streaming support provided by XDN architecture, which frequently isn’t the case with the freezes and fluctuations common to HTTP-based streaming.
Audio Control – Along with benefitting from superior consistency in audio performance mirroring what’s achieved with video on the TrueTime Meetings™ real-time XDN streaming infrastructure, session managers can keep tabs on user-controlled audio levels to ensure satisfactory UX on the part of all participants. Exploiting the Meeting software client’s periodic registering of each participant’s audio level, managers can activate a “talking indicator” to display how audio is playing out in conference conversations.
Support for Text and Emoji Messaging, Screen Sharing, Hand Raising and Meeting Recordings – All of these functionalities are built into the default platform, eliminating the need to engage third-party services or in-house developers.
Layout Flexibility – Operating in auto mode, the TrueTime Meetings™ platform adjusts the display layout based on the participant count. Alternatively, session managers have other options allowing them to set up tiled layouts that allocate equal-sized video tiles to all participants or implement sidebar layouts where the main speaker is prominently displayed with others in a participant sidebar. They can also choose hands-on control over shifts in participant focus throughout the session.
UI Styling – The TrueTimes Meetings™ software stack includes a broad range of styling and branding options that can be easily implemented on user dashboards.

Custom Use of TrueTime Meetings™

Beyond default mode TrueTime Meetings™ can be configured in unique ways as an integral part of any real-time streaming scenario to enable usage formats that depart from the traditional video conferencing structure. Of course, all the capabilities enumerated above for the default mode can be applied in customized applications as well.

Here is where TrueTime Meetings™ meets the full scope of challenges in the new live streaming era, unleashing the unlimited possibilities that emerge when interactive video communications and multicast streams share the same real-time infrastructure. In this hybrid environment any viewer in a live-streamed video audience of any size extending into the millions can seamlessly join in interactive video communications as configured on the TrueTimes Meetings™ platform.

In commercial operations ready-to-deploy face-to-face group interactions can be implemented with real-time XDN streaming in support of dispersed collaboration across a vast range of pursuits, from live sports productions, coordinated engagements of public safety units in emergency surveillance, engineering and architectural design and much else in the workaday world to every type of education and training environment. Anyone anywhere can be connected into the global Red5 Cloud XDN for a role as commentator or influencer in any of these use cases.

Adding to the cost-free versatility, our customers can work with other TrueTime Solutions™ integrated in their workflows to enhance their video calling with additional features related to multiviewing, watch parties, live production and use of telemetric data feeds in sports streaming and surveillance. Moreover, TrueTime Meetings™ users can integrate interactive video communications with the interactive data streaming capabilities enabled by the partnership between Red5 and global data platform operator PubNub.

Aggregations of meeting participants can be displayed anywhere. For example, our customers might prefer to put the TrueTime Meetings™ participation grid on display in a venue setting that makes users part of what’s transpiring at the location. LED walls used with live-streamed game shows, live shopping, reality TV, sports shows with call-in formats, and much else can display large numbers of participants while prominently projecting speakers chosen by the host.

Or maybe there’s no interest in creating multi-participant grids at all, as when customers simply want to accord a video presence to individuals speaking in Q&A sessions during corporate earnings calls and other types of meetings. Or, in another example of unitary displays involving big venues like sports stadiums, in-venue and remote smartphone users alike can participate in a mass shared experience where video generated from anyone’s phone at any moment can be displayed on the stadium screens, as is the case in multiple locations where The Famous Group is bringing such experiences alive in partnership with Red5.

Looking at another use case, ever since the Covid Pandemic, there’s been an interest in adding virtualized functionalities to remote participants in webinars and location-based trade shows, but the attempts at supporting such use cases proved to be too cumbersome and costly to take hold. Now it’s a different story for our XDN customers who want to use the open-source TrueTime Meetings™ tools to create multi-dimensional virtual extensions with their events featuring things like private rooms for booked meetings between remote attendees and vendors.

The Spatial Audio Option

There’s an unmatched level of realism that can be infused into group social interactions enabled by our support for spatial audio. In all situations involving virtualized group interactions, including virtual casinos, virtual sports bars and other online social meeting places, customers who utilize TrueTime Meetings™ can benefit from the value-added spatial audio solution whether or not the use of XR headgear is involved.

We have taken immersive spatial audio to a new level of versatility and scalability by exploiting unique characteristics of XDN Architecture to maintain real-time configurations of realistic audio experiences in 3D space no matter how many users are engaged or how complex the ambient environment might be. Individualized mixes of ambient sound are applied to realistically reflect each user’s position in the virtual space while personal conversational sound levels are raised with one-on-one communications.

A key element in the XDN toolset that makes this possible is our Cauldron transcoding engine, which supports blending of personally directed stream segments with the primary streams in real time. These segments, which we call Brews, can be added in the transcoding process without incurring delays usually caused by the need to translate coding to the languages understood by processors.

As for instances involving XR headgear, these and other unique attributes together with the simultaneous ultra-low latency connecting all participants in AR and VR use cases running on XDN Architecture ensure that TrueTime Meetings™ is readily available to support any socialized XR use case. That means advancements like spatial audio, light detection and arranging (LiDAR) used to add realistic dimensionality to visual displays, and any iteration of spatial computing technology can be effortlessly brought to bear as our customers adapt to next-gen operations in the new world of real-time interactive video streaming.

Conclusion

With flexibility and scalability in interactive video communications as enabled by our TrueTime Meetings™ taking hold over the next few years, the market for interactive video communications across all consumer and non-consumer market segments is likely to take up a much bigger, if not the lion’s share, of the $107.0-billion interactive streaming market Grand View Research projects will be in play by 2030. Leveraging the readily deployable capabilities facilitating implementations of the open-source TrueTime Meetings™ tools through Red5 Cloud or Red5 Pro, operators of live-streamed use cases can act now to bring the new era in video communications to life in their domains.

Try Red5 TrueTime Meetings™ today

Option 1:

Download the source from GitHub

Get the open source code, customize the front end, and deploy in your own environment. This is the best path if you want full control and deeper product integration.

View on GitHub >

Option 2:

Launch it in Red5 Cloud

Get the open source code, customize the front end, and deploy in your own environment. This is the best path if you want full control and deeper product integration.

Option 3:

Deploy with Red5 Pro

Prefer a self-managed setup? Red5 Pro users can download the source and deploy TrueTime Meetings™ in their own infrastructure, then extend it for their application and workflow needs.

Schedule a consultation >

SRT vs MOQT: Low-Latency Video Transport Comparison

Maria Artamonova — Tue, 10 Mar 2026 13:31:31 +0000

Questions about SRT vs MOQT come up often when engineers evaluate low latency video transport options. As a Lead Real-Time Video Architect working on MOQ development at Red5, I ran into this question during architecture discussions and realized others will likely face the same comparison soon. This article is written from my perspective and has also been reviewed and verified by my teammate Paul Gregoire, Red5 Solutions Architect.

If you want a quick summary, read the Key Takeaways section. If you want a deeper technical comparison, continue through the rest of the blog.

Key Takeaways

SRT is a well-established, reliable protocol for video contribution, offering strict end-to-end latency controls. However, its payload-agnostic approach to packet dropping can introduce playback instability under severe congestion, and its single-stream architecture can still create Head-of-Line blocking conditions, limiting its applicability to modern SVC workflows.

MOQT, pairing flexible streaming formats mapped to independent QUIC streams, provides equivalent latency controls while enabling granular, payload-aware data handling and discard strategies. Utilizing parallel streams, isolated packet loss recovery, and priority-based delivery, it can safely drop late data and natively support SVC adaptation. The protocol’s architecture is highly optimized for resilient, low-latency, bandwidth efficient media distribution.

Baseline for Comparison

When comparing Secure Reliable Transport (SRT) and Media over QUIC Transport (MOQT), it is important to establish equivalent architectural layers. Technically, SRT is a payload-agnostic transport protocol. However, in standard broadcast and streaming workflows, it is predominantly used to carry multiplexed MPEG-TS (Transport Stream) payloads.

MOQT is an end-to-end media transport protocol designed to operate in conjunction with a wide range of application-layer streaming formats (current drafts define MOQT Streaming Format (MSF) and CMAF MSF (CMSF). The streaming format and related container structure provides necessary media meta-data including timestamps. Therefore, a functional comparison for video delivery is best framed as SRT + MPEG-TS versus MOQT + CMSF.

Note: it is important to mention that MOQT occupies different use-case spaces, with overlap primarily on the contribution side – SRT is generally not considered for distribution at scale to end-consumers.

Packet Scheduling and Multiplexing

Under network congestion, transport protocols must manage how data is queued and transmitted through restricted bandwidth.

SRT Scheduling: SRT processes packets in a primarily First-In, First-Out (FIFO) sequence over a single UDP connection. Because it does not natively inspect the payload, it cannot differentiate between critical media (like base video layers or audio) and supplemental media (like video enhancement layers) without custom application layer multiplexing.
MOQT Scheduling: MOQT incorporates a prioritization model utilizing various priority parameters per stream. This allows the sender and intermediate relays to identify the relative importance of different media components. Under bandwidth constraints, an MOQT relay can use this logic to selectively delay or drop lower-priority streams to ensure the timely delivery of higher-priority streams.

Packet Loss Recovery and Head-of-Line Blocking

Both SRT and MOQT (via QUIC) use Automatic Repeat reQuest (ARQ) to recover lost packets. When a packet is dropped by the network, the receiver asks the sender to retransmit it. The operational difference lies in how this recovery impacts the rest of the data in transit.

SRT (Head-of-Line Blocking): SRT transmits its payload sequentially over a single connection. If a packet is lost, the receiver must hold all subsequent packets in a buffer until the lost packet is retransmitted and successfully arrives. However, if the retransmission delay exceeds the set latency buffer, SRT drops the packet entirely, allowing the stream to continue rather than waiting forever. This creates Head-of-Line (HoL) Blocking. Because all media (audio, video base layer, video enhancement layer) shares this single pipeline, a single lost network packet stalls the delivery of the entire transport stream, increasing latency across the board. Again this only “stalls” within the latency period, not forever.
MOQT (Independent Stream Recovery): MOQT relies on QUIC’s multiplexed stream architecture. Because different media components (e.g., audio and video) are mapped to independent QUIC streams, packet loss is isolated. If a packet containing video data is lost, only the specific video stream waits for a retransmission. The audio stream, operating on a parallel QUIC stream, continues to deliver data to the application without interruption. This prevents a single network packet loss from stalling the entire media presentation.

Handling Late Data under Congestion

When network delays cause data to arrive past its intended playback deadline, the two protocols use different mechanisms to discard that data.

SRT (Network-Level Dropping): SRT utilizes a configured latency buffer. If a packet cannot be delivered within this timeframe, SRT’s Too-Late Packet Drop (TLPKTDROP) mechanism discards it. Because SRT drops data at the network packet level without payload awareness, this can result in the delivery of partial media frames. In an MPEG-TS workflow, this fragmentation can lead to decoder errors or visual artifacts, potentially persisting until the next keyframe.
MOQT (Application-Aware Dropping): MOQT relies on a feedback loop between the application’s Streaming Format and the QUIC transport layer. The application layer evaluates the Presentation Timestamp (PTS); if a frame exceeds its playback deadline, it instructs the transport layer to issue a QUIC STOP_SENDING frame. MOQT then discards the complete, semantic media unit via a RESET_STREAM operation. This preserves the structural integrity of the remaining video streams and avoids corrupting the decoder.

Support for Video Adaptation (ABR and SVC)

Modern video delivery relies on Adaptive Bitrate (ABR) and Scalable Video Coding (SVC) to adjust to changing network conditions.

SRT and SVC: Because SRT typically carries a single, multiplexed MPEG-TS stream, all SVC layers (base resolution and enhancement details) share the same transport queue. If the network drops a base layer packet while successfully delivering an enhancement layer packet, the enhancement data cannot be decoded, limiting the practical effectiveness of SVC over a standard SRT link.
MOQT and SVC/ABR Integration: MOQT maps SVC layers to independent QUIC streams (Subgroups), facilitating two types of adaptation:
1. Layer Dropping (SVC): During transient network drops, MOQT relays autonomously discard low-priority enhancement Subgroups. The player experiences a temporary reduction in quality while maintaining uninterrupted playback.
2. Track Switching (ABR): For sustained changes in network capacity, the client can issue a SUBSCRIBE command for a lower-bitrate MOQT Track. MOQT processes these switches at defined Group boundaries (Keyframes), providing clean transitions between quality tiers.

Integration with Transcoding Workflows

The integration of these protocols into transcoding pipelines involves a tradeoff between current ecosystem support and architectural efficiency.

SRT Ecosystem Maturity: SRT combined with MPEG-TS is a mature, widely adopted standard. It possesses extensive support across legacy hardware encoders, software transcoders (e.g., FFmpeg), and existing cloud broadcast infrastructure.
MOQT Processing Efficiency: SRT’s monolithic payload requires transcoders to ingest, demultiplex, and decode the entire Transport Stream before processing. By contrast, MOQT’s architecture separates media into independent Tracks and Subgroups. This allows a modern transcoder to selectively ingest only the required streams (e.g., processing a 1080p base layer while actively ignoring higher-resolution streams), offering a more compute-efficient pipeline as the software ecosystem matures.

Conclusion

In summary, the SRT vs MOQT comparison highlights the difference between a mature contribution protocol built around a single transport stream and a newer architecture designed for multiplexed, media aware delivery. SRT remains widely used and reliable, while MOQT introduces transport level capabilities that align better with modern scalable video workflows and adaptive streaming models.

If you want to explore how MOQ compares with other real time delivery approaches, read our related blog on MOQ vs WebRTC.

Why The Term “Smart City Surveillance” Needs An Update In The Era Of AI And 5G

Maria Artamonova — Wed, 04 Mar 2026 14:19:56 +0000

Smart city surveillance is rapidly evolving beyond traditional monitoring, thanks to real-time streaming technologies, AI, and 5G. In this blog, based on my recent LinkedIn post, you’ll learn the definition of smart cities and how the concept is evolving in 2026, gain an overview of the market, see how AI is revolutionizing this space, and discover what technology capabilities are now available to transportation agencies, public safety departments, disaster response teams, and other groups using smart city solutions.

What Is A Smart City?

A smart city is an urban area that uses smart technologies like ICT, IoT, and real-time streaming to enhance services and improve quality of life. With connected cameras, sensors, and software, cities can monitor feeds, detect incidents, and balance safety with privacy. These technologies integrate data-driven decision-making into everyday operations.

Smart City Market Overview

According to Statista, the United States is at the forefront of smart city development, with cities like New York and San Francisco leading the way in implementing advanced technologies for efficient infrastructure and improved quality of life. In terms of global comparison, the United States is projected to generate the highest revenue, with US$27.06 billion expected in 2025. It is anticipated that the revenue will demonstrate an annual growth rate (CAGR 2025–2029) of 7.27 percent. This growth will lead to a market volume of US$35.84 billion by 2029.

The U.S. government is also putting real momentum behind smart city innovation. Congress passed the Smart Cities and Communities Act of 2024 and followed with the 2025 version, both designed to fund projects, create standards, and boost cybersecurity. The Department of Transportation is running the SMART Grants Program, channeling resources into connected transportation and safety. On top of that, agencies like NIST and NSF are pushing research that takes these ideas well beyond big cities and into the communities where people actually live and work.

The Future Of Smart Cities

I’ve been thinking about that a lot lately as we’ve worked on projects that go well beyond the traditional “smart city” pitch deck.

With modern AI and real-time video infrastructure combined with growing 5G connectivity, we’re no longer limited to passive surveillance or slow post-event analysis. Today, systems can detect critical conditions as they unfold, so humans can intervene faster, or in some cases, not intervene at all.

One problem I have with the term “smart cities” is that so many of the use cases have nothing to do with cities at all. We’re not just talking about big city surveillance. These “smart city” systems are already being used by regional transportation agencies, public safety departments, and disaster response teams which cover rural areas too. Smart Cities was probably the right term when it was created, but times have changed. With today’s low-cost cameras, 5G connectivity, and cloud-hybrid infrastructure, it’s possible to put intelligence at the edge everywhere.

How Does AI Improve Smart City Surveillance?

In these new deployments, AI-based video analytics does a lot of the heavy lifting in video surveillance. The job of the operator becomes less about staring at feeds and more about responding to actionable insight. For example:

Cameras detect crowd congestion in a stadium and reroute foot traffic.
A traffic feed flags a stopped vehicle inside a tunnel and alerts rescue teams in real time.
Edge-based systems detect early signs of wildfires or floods and trigger rapid response, potentially saving lives.
Teams can even record and share key footage as on-demand video with law enforcement to aid in investigations.

I talked about at the RTC.On conference in Poland in September 2025. My talk, “The Future in Focus: AI and the Next Wave of Real-Time Video Intelligence”, explored large language models (LLMs) and Red5 Pro’s Brew API can be used to detect everything from crowd control issues and forest fires to firearms and inappropriate content in live user streams. I also walked through real-world architectures and what’s coming next in this space. If you’re interested to know more, watch this recording on Youtube:

Cameras Everywhere? Finding The Right Balance

“What about big bother?” you might ask. “Should we have cameras like this everywhere?” This is honestly a difficult question. There’s a saying that with every new technology it can be used for good and for evil. Plus, it’s pretty clear that the cat is out of the bag, and we aren’t going back. I prefer to embrace the possibilities and do what we can to prevent the bad stuff while enabling life saving use cases that make a difference. Cameras everywhere can actually be a good thing if we use them with the right intent, the right architecture, and the right safeguards.

At Red5, we’ve built streaming infrastructure for smart cities that supports all of this:

Ultra-Low Latency Streaming. Our sub-250 ms latency and ability to ingest video at the edge, feed it directly into GPU-powered AI models, and share results instantly, whether live or as on-demand content.
Cross-Department Sharing. Seamlessly share video feeds across traffic management, emergency services, and public safety departments while maintaining secure access controls.
Scalable City-Wide Deployment. Support thousands of cameras across urban environments while maintaining sub-250ms latency for real-time monitoring and response.
Automated Alert System. AI-powered detection automatically alerts relevant departments to incidents, from road hazards to emergency vehicle deployment.
Flexible Infrastructure Integration. Integrate with existing urban infrastructure and camera systems while enabling future expansion and technology adoption.

Conclusion

Smart cities are no longer just about urban infrastructure. With AI, 5G, ultra-low latency streaming, and edge-powered analytics, surveillance systems can now detect issues as they unfold and support faster, safer decision making. Follow me on LinkedIn to keep up with my latest #ChrisAllenTalks posts and videos. Learn more about the AI technology is changing live streaming in our next blog.

The Future of News Broadcasting Is Real-Time, Decentralized, and Participatory

Maria Artamonova — Mon, 02 Mar 2026 14:37:49 +0000

In this blog, based on my recent LinkedIn post, you’ll learn how the future of news broadcasting is being shaped by real-time video in a world of misinformation, how decentralized and participatory models are redefining coverage, what streaming technologies leading newsrooms are adopting, and how these shifts set new standards for speed, authenticity, and audience engagement.

Through our integration, we can connect directly to those existing streams. This makes it easy to add real-time multi-view layouts and give teams instant access to live feeds, all without requiring a complete overhaul of their current workflow.

In major newsrooms, producers are using Red5’s TrueTime MultiView™ to build real-time monitoring walls. These setups help teams track multiple breaking stories at once while keeping every feed in perfect sync. It’s a game changer for fast-paced editorial decision-making.

Field reporting has gotten a boost too. With Red5’s adaptive bitrate streaming, news organizations are keeping clean, stable connections with on-site reporters, even in remote areas or on unreliable networks. Reporters stay connected, editors stay in control, and the audience gets coverage that feels truly live.

It’s been rewarding to watch these teams move beyond patchwork tools and start building systems that actually support the speed and complexity of today’s news cycle.

Conclusion

If you’re a product lead or technology decision-maker inside a traditional broadcast news organization, this is your moment. Real-time infrastructure and participatory models are no longer fringe experiments. They are quickly becoming the standard. Audiences expect immediacy, interactivity, and authenticity. If your stack still relies on delayed workflows and closed-loop production, you’re going to lose relevance fast.

To stay competitive and credible, it’s time to embrace the shift. Real-time video, real audience participation, and real agility in your newsrooms. The future won’t wait.