DEV Community: Red5

What is HLS Streaming? HTTP Live Streaming Explained

Maria Artamonova — Thu, 14 May 2026 14:16:29 +0000

Over the past two decades, the media industry has undergone a significant transformation, introducing a wave of new concepts and technologies such as OTT, streaming, connected TV, DASH, and HLS. Even as a streaming media professional, I often find myself going back to the basics; searching for clear definitions and practical explanations of these evolving terms. This blog aims to provide a simple and practical introduction to one such concept: What is HLS?

What is HTTP live streaming (HLS)?

HLS is an adaptive bitrate streaming protocol developed by Apple back in 2009 originally for devices in the Apple ecosystem. This streaming protocol delivers audio-video segments over standard HTTP connections with latency from 10 to 30 seconds. Although it is called HTTP live streaming, it is used for both on-demand video streaming and live streaming.

A major advantage of HLS is its adaptive bitrate streaming. On the server side a stream can be encoded/transcoded in multiple renditions at various bitrates. When a client (HLS player on an end user device) requests content from the server, the player selects the most suitable video rendition in real time. The player also keeps a buffer of segments in case it loses network connection, minimizing disruptions for the end user. This adaptive bitrate streaming keeps playback stable, even when network conditions change.

How Does It Work?

Let’s take a deeper look at the end-to-end process a media asset goes through to be delivered as an HLS stream:

Ingest: Let’s say you have a camera setup (live streaming) or standalone media content file on a local device (VOD) which will be considered as original media content. This content can be in 1080p or 4K (aka 2160p) available to you at the highest bitrate.
Encoding/ Transcoding: A software or hardware encoder creates variants of the original media content as per the requirements. Usually this involves settings related to codecs (i.e AV1, H264, H265 for video, AAC or AC3 for audio), bitrates, frame rates, resolutions etc. Sometimes original media content needs to be transcoded i.e. converting one codec to another for compatibility reasons. For example, if the original media content is 4K with 5.1 AAC audio, then the encoder will create renditions of video at 480p@500kbps, 720p@1Mbps, 1080p@2Mbps, 2160p@8Mbps and audio at 2ch AAC@64kbps, 5.1ch AAC @256kbps and 2ch AC3@128kbps. The encoding process also involves other settings that need to be considered such as GOP, GOP size, frame rate, keyframe, sample rate for audio etc.
Packaging: An extension to encoder is called packager (also referred as segmenter). This packager considers media content’s frame rate and GOP size during segmentation into smaller segments (2 to 12 seconds long). These video segments files (.ts or .mp4) are indexed by a manifest file. The packager creates manifest files for every rendition/variant (i.e one each for 480p, 720p, 1080p & 2160p) and in the end it creates a master manifest file aka playlist file which refers to all the variant manifest files. For HLS, the manifest files are created with the .m3u8 extension.

Commonly, these packaged files (manifests and segments) are stored on the origin server and pushed out to the client over the internet (using HTTP protocol) when the player requests the content from the server. Typically, a content delivery network (CDN) will help distribute this packaged content.

The client requests the content master manifest URL (from a content delivery network) when an end user hits the play button on the HLS player. The client then selects a variant to play depending on the network bandwidth and fetches variant manifest (aka index) file as a reference for assembling the audio-video segments in order and it switches from higher quality to lower quality picture (and vice versa) as needed (depending on device display size, network bandwidth availability, etc).

In some use cases I have seen, HLS is combined with WebRTC to support both scalable playback or VOD delivery with real-time interaction. These workflows rely on switching between protocols depending on the viewing experience required. Emerging technologies like MOQ (Media over QUIC) are expected to provide these capabilities under one roof while simplifying the overall architecture.

When and Where Can You Use It?

HTTP live streaming is a widely compatible, scalable, secure and reliable egress streaming protocol, making it a strong fit for workflows where video and audio need to be delivered to massive global audiences and latency is not critical.

For example, HLS is commonly used in video-on-demand (VOD) workflows because of its broad compatibility across platforms, browsers, and devices. It is supported by major streaming platforms and ecosystems such as Netflix, Amazon Prime, Roku, Apple TV+, etc.

Benefits & Drawbacks

Benefits of HLS:

Compatibility: Can be used on all types of devices and platforms.
Adaptive bitrate streaming: Adapts to the varying network/bandwidth situations.
Scalability: With the help of CDN, events can be streamed worldwide.
Secure: Support encryption (AES-128, FairPlay) of the content and hence restricts unauthorized access.
Accessibility: Support closed captions, alternate audio tracks, audio description, etc.
Monetization: With support of advertising integration such as SCTE markers, Ad Interstitials, Discontinuity flags etc HLS can be used to monetize streaming.

Drawbacks of HLS:

Latency: Standard HLS has latency around 10 to 30 seconds which is not ideal during live streaming
Storage costs: Multiple renditions and segmentation increases costs.
Content creation complexity: Higher computational load due to encoding overheads.

HLS Video Streaming Compatibility

Over the past decade, I’ve worked extensively with HTTP live streaming as the de facto streaming protocol across a wide range of use cases, and it has consistently delivered reliable, high-quality performance. Based on this experience, it’s clear that HLS offers broad compatibility across:

Platforms: Apple, Android, Roku, Amazon Fire, Sony PS, Microsoft Xbox, Comcast Xumo, LG WebOS, Samsung Tizen, etc.
Video Codecs: H264, H265, AV1, MPEG 2, HDR, HDR10+, Dolby Vision etc.
Audio Codecs: AAC, HE-AAC, Dolby AC3, Dolby EC3, Dolby Atmos, etc.
Container Formats: MPEG-TS, fmp4 (CMAF/ .m4s/ .m4a) etc.

Does HLS Use TCP or UDP As Its Transport Protocol?

TCP and UDP are transport protocols responsible for delivering data over the internet. HLS operates over HTTP, which in turn relies on TCP, leveraging its reliable and ordered delivery mechanism to transport video segments. This ensures that all segments arrive intact and in sequence, minimizing packet loss and preventing video corruption; prioritizing playback stability and quality over raw speed. In contrast, UDP, which is used by protocols such as SRT and WebRTC, offers lower latency but does not guarantee delivery, making it more prone to packet loss.

Because HLS is delivered over HTTP, it behaves like regular web traffic, allowing it to seamlessly traverse firewalls and work across standard internet infrastructure. While UDP-based protocols are faster, TCP’s reliability makes it better suited for HLS’s segmented delivery model, where consistent and complete delivery of each segment is critical for smooth playback.

HLS vs. Alternative Streaming Protocols

If you’re choosing a live streaming protocol for your application and weighing different options, the best approach is to compare them side by side to see which one fits your use case best. Below, I’ve covered the protocol comparisons developers ask about most often.

HLS vs RTMP

HLS is primarily an egress/playback protocol, whereas RTMP is mainly used for ingest and contribution workflows. HLS is optimized for content delivery and is rarely used for ingestion. It relies on segments and manifest playlists, which introduce higher latency but enable massive scalability through CDN-based distribution.

RTMP, on the other hand, offers lower latency and was once widely used for both ingest and playback during the Adobe Flash era. However, as Flash declined, playback shifted toward HTTP based live streaming protocols such as HLS. Today, RTMP continues to be commonly used for contribution and encoder-to-platform ingest workflows, while HLS remains the dominant protocol for large-scale playback across modern streaming devices and platforms. Read a detailed HLS vs RTMP comparison in our previous blog.

HLS vs WebRTC

HLS is a streaming protocol designed for scalable streaming, whereas WebRTC is a broader real-time communication framework composed of multiple protocols, codecs, and JavaScript APIs that enable ultra-low-latency peer-to-peer communication. HLS follows a client-server delivery model over TCP/HTTP, which results in higher latency but provides reliable playback and seamless scalability through CDNs.

WebRTC, on the other hand, is primarily UDP-based and optimized for real-time interaction, enabling sub-second latency for applications such as video conferencing, live collaboration, and interactive streaming. While HLS scales efficiently to millions of viewers using CDN infrastructure, scaling WebRTC can be significantly more complex due to its peer-to-peer communication architecture and real-time processing requirements. See our previous blog for a detailed comparison of HLS vs WebRTC.

HLS vs DASH

HLS and MPEG-DASH (Dynamic Adaptive Streaming over HTTP) are both HTTP-based streaming protocols that deliver high-quality audio-video over the internet using CDN. HLS, developed by Apple, is essential for Apple ecosystem compatibility, while DASH is an open-standard, codec-agnostic alternative commonly used for Android and web browsers.

HLS vs LL-HLS

LL-HLS is an extension of standard HLS designed to significantly reduce streaming latency. Traditional HLS typically uses segment durations of 2 to 12 seconds, which contributes to higher end to end latency. LL-HLS improves this by introducing partial segments, often less than one second in duration, reducing latency to approximately 2-3 seconds. In addition to lower latency, LL-HLS optimizes data transfer by delivering incremental playlist updates and smaller media chunks, making it more efficient than traditional HLS, which relies on larger segments and full playlist refreshes.

HLS vs MOQ

MOQ is an emerging open standard being developed by the IETF to unify real-time, sub-second, and on-demand video within a modern next-generation live streaming protocol. Because it relies on UDP, MOQ can achieve sub-second latency, though it is also more susceptible to packet loss. In contrast, HLS uses reliable TCP-based delivery, which comes with higher latency trade-offs. HLS distributes content through a client-server model over CDNs, while MOQ uses a publish-subscribe approach over QUIC relays. Although MOQ is still in its early stages, the media industry is actively exploring it as a potential next-generation solution for real-time content delivery.

Does Red5 Support HLS?

Depending on your level of control and customization needs, you can live stream video and audio with HLS streaming protocol with wide device support, adaptive bitrate, and massive scalability through CDNs, with latency from 20 to 60 seconds to millions of viewers, we have got you covered. Visit our demo page, connect your camera and microphone, and experience HLS playback for yourself. Then read “How to Use HLS Streaming with Red5 Pro and Red5 Cloud” blog.

1. Red5 Cloud

If you want a fully managed, globally distributed streaming solution with an intuitive dashboard, Red5 Cloud is the easiest place to start. Sign up with no credit card required and get the free tier every month:

50 GB of streaming.
6,000 instance hours.
Hosting in US Central.
Access to documentation and email support.

Once you reach the 50 GB monthly limit, you can:

Continue streaming immediately with our usage-based pricing model, Pay-As-You-Grow, at $0.08 per GB and $0.69 per instance hour. No monthly minimums and no fixed commitments.
Or wait until the next monthly cycle for your free 50 GB to reset.

Check out this Youtube playlist to get started with Red5 Cloud.

2. Red5 Pro

If you need full customization, maximum flexibility, and complete control over your infrastructure, choose Red5 Pro, our server software built for ultra-low latency streaming at scale. Start with a 30-day trial and get access to all capabilities without limitations.

Learn more about HLS egress support in Red5 Pro and HLS plugin in our documentation.

Choosing the Right Setup

Not sure which solution is the best fit for your streaming challenges? Visit our product comparison page or contact us to discuss your project.

Conclusion

So if you ask me “what is HLS”, I would say a widely adopted HTTP-based adaptive streaming protocol used to deliver audio-video reliably across devices by breaking content into small segments and dynamically adjusting quality based on network conditions. Its scalability via CDNs and broad compatibility make it the backbone of modern streaming workflows.

FAQs

What does HLS stand for?

HLS stands for HTTP Based Live Streaming. It is a streaming protocol developed by Apple in 2009 and primarily used for content delivery. It distributes segmented video to viewers across browsers, mobile devices, and smart TVs with broad compatibility. Because it is optimized for playback rather than contribution, it is rarely used for ingest workflows. Its reliability and scalability make it well suited for reaching large audiences.

Which browser supports HLS?

HLS is natively supported across the Apple ecosystem through the built-in AVPlayer framework, including playback in Safari browsers. On other modern browsers such as Microsoft Edge, Google Chrome, Firefox, and Brave, HLS is not natively supported but can be played using HTML5-based players (e.g., via JavaScript libraries like hls.js) that enable compatibility.

Is Netflix HLS?

Yes, Netflix uses HLS for delivery specifically on Apple devices because of native playback support. While HLS is used for compatibility across many devices, Netflix also heavily uses MPEG-DASH as a primary, standardized protocol. For live content, Netflix uses HLS with CMAF to ensure reliability across devices.

What is an HLS Stream?

HLS Stream is a package created after encoding-transcoding-packaging. Many software/hardware tools create this package which usually consists of a master manifest file (aka playlist file), variant manifest files, audio-video chunks etc.

What is an HLS Playlist Link?

For delivery, HLS typically relies on CDNs to scale efficiently. To make content available, the HLS stream (packaged assets) is hosted on a CDN. Once published, the CDN URL pointing to the master manifest file (also known as the playlist) serves as the HLS playback URL, which client players use to request segments and start streaming the content.

How to stream with HLS for free?

You can start streaming with HLS right away using our fully managed, globally distributed streaming PaaS solution, Red5 Cloud. No credit card is required to sign up, and you’ll get 50 GB of streaming free each month. If you need more flexibility in deployment, you can also begin a 30-day free trial with Red5 Pro to explore custom setups.

What Is RTSP Streaming and Why It Is Still Relevant in 2026

Maria Artamonova — Fri, 08 May 2026 08:29:53 +0000

What is RTSP, and why is it still widely used in modern streaming workflows? RTSP, or Real Time Streaming Protocol, is a control protocol designed for managing real-time audio and video streams, especially from devices like IP cameras and encoders. In this guide, I will explain how RTSP works, where it fits in the streaming pipeline, and why it remains relevant in 2026.

What is RTSP?

The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. It provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (source: the official 2326 RTSP standard published in April 1998.)

Developed by experts from RealNetworks, Netscape, and Columbia University around 1996, the protocol defines how the data in the stream should be packaged for delivery. It also defines how both ends of the connection should behave to prepare a pathway for transportation.

RTSP Technical Specifications

To get a high-level understanding of this protocol’s technical capabilities, security, and primary use cases, see the information below.

Video Codecs: H.265 (HEVC), H.264 (AVC), VP9, VP8.
Audio Codecs: AAC, AAC-LC, HE-AAC+ v1 & v2, MP3, Speex, Opus, Vorbis.
Variant Formats: RTSP as an umbrella term describes the entire stack of RTP, RTCP (Real-Time Control Protocol), RTSPS (RTSP over SSL / Secure RTSP), and good-old RTSP.
Encryption: Basic, less standardized.Native RTSP has no built-in encryption. RTSPS over TLS (port 322).
Playback Compatibility: Limited support and rarely used for end-user playback.
CDN Friendly: No.
Use Cases: IP camera ingest, CCTV, surveillance, NVR (Network Video Recorder), DVR (Digital Video Recorder), streaming from drones and robots.

RTSP Methods

RTSP defines a set of case-sensitive methods used to control operations on media resources identified by a Request-URI. Each method token specifies the action to be performed on a presentation (P), a stream (S), or both, and can be sent from client to server (C→S) or, in some cases, from server to client (S→C). Methods must follow the RTSP token format (they cannot start with the “$” character), and the protocol is extensible, allowing new methods to be introduced beyond those defined in the specification. The standard methods and their behavior are summarized below.

Method	Direction	Description
OPTIONS	C→S, S→C	Queries the server for supported RTSP methods and capabilities. Sent by both client and server. Required for capability negotiation and typically the first request in a session.
DESCRIBE	C→S	Retrieves the session description (SDP), including codecs, bitrate, and transport parameters. Sent from client to server. Recommended for initializing playback.
ANNOUNCE	C→S, S→C	Sends or updates the session description. From client to server, it describes the presentation; from server to client, it updates it. (optional)
SETUP	C→S	Defines how media will be transported (e.g., RTP over UDP or TCP, port ranges) before playback begins. Sent from client to server. Required to establish the stream.
PLAY	C→S	Starts media delivery by instructing the server to begin sending RTP packets. Sent from client to server. Required for playback.
PAUSE	C→S	Temporarily halts media delivery without terminating the session. Sent from client to server. Recommended for session control.
RECORD	C→S	Initiates recording of the media stream on the server. Sent from client to server and used in publishing workflows. (optional)
REDIRECT	S→C	Instructs the client to connect to a different server by providing a new URL. Sent from server to client. (optional)
TEARDOWN	C→S	Terminates the RTSP session and stops all associated media streams. Sent from client to server. Required for session cleanup.
GET_PARAMETER	C→S, S→C	Retrieves parameter values (such as session state or keepalive info). Can be sent by both client and server, often used for keepalive. (optional)
SET_PARAMETER	C→S, S→C	Sets or updates session parameters. Can be sent by both client and server. (optional)

How Does RTSP Work?

RTSP is a stateful control protocol used to manage media streaming sessions while separating signaling from media transport. The client communicates with the server over a persistent TCP connection, sending requests that define how the stream should be delivered, including the application type, requested media, and transport mechanisms such as unicast or multicast over UDP or TCP.

An RTSP session typically follows this sequence:

OPTIONS: The client queries the server to discover supported methods and capabilities.
DESCRIBE: The client requests an SDP (Session Description Protocol) file describing the media, including codecs, bitrate, and transport parameters.
SETUP: The client specifies how the media will be delivered, negotiating transport options such as RTP over UDP or TCP and defining port ranges.
PLAY: The server begins sending media data.
PAUSE / TEARDOWN: The client can temporarily halt or fully terminate the session.

RTSP itself does not transport media. Instead, audio and video are delivered separately using the Real-time Transport Protocol (RTP), typically alongside the Real-time Control Protocol (RTCP) for synchronization and quality feedback. Secure transport can be achieved using SRTP. In practice, RTSP protocol is most commonly used for first-mile delivery (ingest), such as streaming from IP cameras or encoders into a media server.

Benefits and Drawbacks

RTSP remains a widely used protocol for ingesting real-time video, but like any technology, it comes with both strengths and limitations.

Benefits of RTSP Streaming

Ultra-low latency streaming: RTSP streams typically achieve latency under one second, making the RTSP protocol suitable for real-time monitoring and control use cases.
Native support in RTSP cameras: Most IP cameras output an RTSP stream by default, making it easy to integrate RTSP camera feeds into a streaming workflow without additional configuration.
Flexible transport options: RTSP supports both TCP and UDP for media delivery, allowing developers to optimize performance based on network conditions.
Efficient RTSP server workflows: An RTSP server can manage multiple RTSP streams from cameras and encoders, making it a reliable choice for ingest pipelines.

Drawbacks of RTSP

Limited playback support: RTSP playback is not supported natively in modern browsers or most mobile devices, which requires conversion to other formats.
Not CDN-friendly: RTSP streams cannot be distributed at scale using standard CDN infrastructure, limiting its use for large audiences.
Requires RTSP URL configuration: To access a stream, you need a properly formatted RTSP URL, which can vary between devices and vendors.
Security depends on implementation: RTSP does not include encryption by default, so secure transport requires additional protocols like RTSPS or SRTP.

3 Reasons RTSP Streaming is Still Relevant

1. Better for a Client-Server Model

Unlike WebRTC, RTSP is a little simpler to run as it does not perform all the signaling and NAT traversal techniques that WebRTC does. This is mainly because RTSP was designed to send and receive media streams from media servers in a client-to-server model, as opposed to WebRTC which was designed as a peer-to-peer protocol. With each WebRTC connection, you also have to maintain a separate signaling connection, whether that’s WebSocket’s or the new web standards WHIP and WHEP. With RTSP, there’s a single connection per subscriber/publisher client. Without the higher overhead of WebRTC, RTSP streams put less strain on the server and thus allows for more connections. We have detailed the WebRTC signaling process in another post.

2. Many Supported Devices

The RTSP protocol provides for incredible cross-device compatibility.

IP Cameras

Since IP cameras have been around since the 90s they were one of the earliest adopters of the Real Time Streaming Protocol for streaming, and thus they still continue to use it today. If it ain’t broke, don’t fix it. There are various uses for IP cameras, such as traffic monitoring for reporting or enforcement, security surveillance, and even home monitoring. Acting as a video streaming server to support multiple IP cameras ingest streams continues to be one of the most common use cases for Red5 Pro. This solution combined with Red5 Pro’s highly scalable clustering model allows for virtually unlimited numbers of concurrent RTSP streams from many cameras.

Other IoT Devices

Drones enjoy widespread use expanding well beyond a backyard hobby. Smartphone or laptop controlled drones can be guided with the assistance of a live video feed (often an RTSP stream). Firefighters and U.S. Border patrol agents have used drones to conduct operations for public safety and defence. Additionally, aerial surveying is useful for maintaining infrastructure by examining power lines, and roads or even conducting geologic surveying. RTSP support is often built right into the drone software and is a common way to access a drone’s video stream in near real-time.

When connecting the video stream from the drone to an RTSP compatible media server, or even a cluster of media servers, it’s possible to scale the number of viewers of the RTSP stream to as many users as needed. In critical military or first responder use cases, this real-time one-to-many stream can be reviewed with other agencies, high ranking officials, and others to make critical decisions. Most current implementations of this use case involves a high latency stream, usually using high latency streaming HTTP based protocols like HLS (HTTP Live Streaming Protocol) which incurs many seconds of delay. An RTSP to WebRTC solution brings the latency down so that decision makers can make critical calls immediately since the video stream is being captured and transported in mere milliseconds.

A great example of this is the San Diego Sheriff’s Department use of Red5 Pro with Nomad Media for real-time drone streaming, allowing for a cost effective solution deployed on AWS to remotely monitor fires, natural disasters, and other emerging situations.

Robots

From underwater submersibles and radiation tests to bomb diffusing, robots are being created for a variety of video streaming applications. As a well-established solution with very low latency, robot-based computer systems will typically use the RTSP protocol for video delivery. The use of video allows the operator to control the robot and perform a wide variety of operations. Among the most impactful are medical robots such as remote surgery and telepresence robots, which enable doctors to communicate and work in isolated areas. Clearly, real-time latency, measured in milliseconds, is key to this use case.

As is the case with the first responder/military example mentioned above, scaling the single RTSP stream to many viewers can be an important aspect. The use of multiple RTSP servers set up in a cluster to fan out the delivery of the media stream to many viewers (other surgeons/experts) makes real-time collaboration possible.

Luckily, the RTSP protocol, with its ability to transport over UDP using secure RTP and connect to compatible media servers, means it is well-suited for these types of applications.

3. Ultra-Low Latency

By using the efficient RTP protocol, RTSP achieves a very low latency: well under 500 milliseconds when used with Red5 Pro. As RTP also forms the underlying protocol for WebRTC, most RTSP implementations are essentially a stripped-down version of WebRTC. One can get the same performance without the complexity.

In order to achieve this low latency, RTP sends video and audio data in small chunks suitable for quick transmission between the servers and clients. Each chunk of data is preceded by an RTP header; RTP header and data are in turn contained in a UDP packet. As each packet is processed, the following packets may already be in the stage of decompression or demultiplexing.

To cope with the occasional loss of packets (a hazard of Internet delivery in general), the RTP header contains timing information and a sequence number that allows the receivers to reconstruct the timing produced by the source. So if anything is out of order it can be quickly organized in proper order for playback.

The general structure of RTP consolidates essential information which in turn streamlines the process of media delivery. Thus it can achieve effective delivery of media streams with very low latency.

For a very detailed explanation of how RTP works please refer to our blog article on WebRTC. Curious how RTSP stacks up against other protocols? Read our RTMP vs RTSP blog to learn where each fits best in live streaming.

RTSP vs. Alternative Streaming Protocols

RTSP is primarily used for first-mile delivery (ingest), so it only makes sense to compare it with other ingest protocols. Comparing RTSP to playback-focused technologies like HLS or Media over QUIC (MOQ) is misleading because they operate at different stages of the streaming pipeline. RTSP brings streams into your system, while those protocols deliver video to end users.

Below is a high-level comparison of RTSP and other common ingest protocols.

RTSP vs RTMP

RTMP is one of the most widely supported ingest protocols, especially for live streaming to platforms like YouTube, Facebook, and Twitch. While RTSP is commonly used by IP cameras and surveillance systems, RTMP is the default output for software encoders such as OBS, Wirecast, and vMix. RTMP runs over TCP and is easier to integrate with streaming platforms, but it typically introduces higher latency (250ms-3s) than RTSP (<100ms). Read a detailed comparison in our RTMP vs RTSP guide.

RTSP vs WebRTC

WebRTC is designed for real-time, interactive streaming with sub 250ms latency and built-in browser support. Unlike RTSP, which is used for controlled ingest from devices like cameras, WebRTC can be used end-to-end, from ingestion to playback. However, ingesting via WebRTC often requires additional signaling and infrastructure compared to RTSP. These protocols are often used together, with RTSP for ingest and WebRTC for ultra-low latency delivery.

Read a detailed comparison in our RTSP vs WebRTC guide.

RTSP vs SRT

SRT (Secure Reliable Transport) is optimized for streaming over unpredictable networks such as the public internet. It provides packet loss recovery, encryption, and adaptive retransmission, making it more reliable than RTSP in unstable conditions. While RTSP is still widely used in controlled environments like local networks and surveillance systems, SRT is gaining adoption for contribution workflows that require both low latency and reliability.

RTSP vs MPEG-TS UDP Multicast

MPEG-TS over UDP multicast is used in broadcast and IPTV environments to efficiently deliver a single stream to multiple recipients on the same network. Unlike RTSP, which typically operates in a unicast client-server model, multicast reduces bandwidth usage by sending one stream to many viewers simultaneously. However, it requires specialized network infrastructure and is not suitable for public internet delivery.

RTSP vs Zixi

Zixi is a proprietary protocol designed for high-quality contribution over managed and unmanaged networks. It includes advanced error correction, congestion control, and monitoring capabilities. Compared to RTSP, Zixi is more robust in large-scale broadcast workflows but requires licensed infrastructure and ecosystem support.

Using Red5 as Your RTSP Server

Depending on your level of control and customization needs, you can use either of our real-time streaming products to ingest RTSP streams from encoders, NVRs, CCTV systems, IP cameras, or drones. If you’re wondering how to view an RTSP stream in a browser, we’ve got you covered.

1. Red5 Cloud

50 GB of streaming.
6,000 instance hours.
Hosting in US Central.
Access to documentation and email support.

Once you reach the 50 GB monthly limit, you can:

Continue streaming immediately with our usage-based pricing model, Pay-As-You-Grow, at $0.08 per GB and $0.69 per instance hour. No monthly minimums and no fixed commitments.
Or wait until the next monthly cycle for your free 50 GB to reset.

Check out this Youtube playlist to get started with Red5 Cloud.

2. Red5 Pro

Red5 Pro is a great fit for high-stakes environments such as public safety and defense, government systems, traffic monitoring, and smart cities.

Choosing the Right Setup

Not sure which solution is the best fit for your streaming challenges? Visit our product comparison page or contact us to discuss your project.

Conclusion

What is RTSP in today’s streaming landscape? It is still one of the most reliable protocols for ingesting real-time video from devices into streaming systems. While it is not designed for direct playback, RTSP remains essential for workflows that require low latency, device compatibility, and efficient first-mile delivery.

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.