DEV Community: Akeel Almas

MoQ Support Is Now Available in Ant Media Server

Akeel Almas — Wed, 20 May 2026 10:33:20 +0000

Home
›
Announcement
›
MoQ Support Is Now Available in Ant Media Server
moq-hero

Petar Ostojic
Author
Apr 17, 2026
12 min read
We are excited to announce that MoQ support is now available in Ant Media Server. Media over QUIC (MoQ) is one of the most interesting developments in live streaming right now, and we wanted to get early support out so you can start experimenting with it alongside us.

In this post, we walk through what the AMS MoQ plugin offers, how it works under the hood, and everything you need to know to get started.

moq-hero
Table of Contents
What Is MoQ?
Introducing MoQ Support in Ant Media Server
MoQ vs. WebRTC vs. HLS
moq-lite vs. Full IETF moq-transport: Where Things Stand
How It Works: Architecture Overview
Built-In Browser Player and Publisher
Supported Codecs
Getting Started
Playing Streams via MoQ
Publishing Streams into AMS via MoQ
Configuration
Frequently Asked Questions
Conclusion
What Is MoQ?
Media over QUIC (MoQ) is an emerging live media protocol built on QUIC and WebTransport. It is being standardized by the IETF working group and has backing from Google, Cisco, Akamai, Cloudflare, and others, which gives a clear signal of where the industry is heading.

At its core, MoQ is built on QUIC, a modern transport protocol that handles multiple streams of data independently over a single connection. This means a delayed video frame will not hold up the ones behind it, which is a known limitation of older TCP-based delivery used by protocols like HLS. On top of QUIC, MoQ uses WebTransport to make this accessible directly from the browser, with no plugins or native apps required. The end result is latency in the range of WebRTC, with a delivery model that scales through a CDN just like HLS does.

If you want a deeper technical comparison, read our article WebRTC vs. MoQ — Two Protocols, One Platform Completely Built for Both. In this post, we focus on the practical: what the AMS MoQ plugin does and how to use it.

Introducing MoQ Support in Ant Media Server
Heads up
MoQ is still an evolving protocol. The IETF standard is actively being developed, and the current plugin is based on moq-lite, a pragmatic and deployable subset of the specification. We are continuously monitoring the standard’s progress and will ship updates as it matures. We recommend keeping that in mind when planning your integration.
The AMS MoQ plugin adds bidirectional MoQ support to any Ant Media Server deployment:

Egress
AMS → Browser Viewer
Live streams on AMS are automatically published as MoQ broadcasts. Browser clients connect via WebTransport and receive video with sub-second latency. No plugins, WebRTC peer connections, or SFU infrastructure required.
Ingest
External MoQ Relay → AMS
AMS can pull streams from any moq-compatible relay and treat them as regular AMS broadcasts, available for recording, transcoding, or re-distribution via WebRTC, HLS, or RTMP.
The plugin ships with an embedded moq-lite-relay (running on port 4443), so there is no extra infrastructure to stand up for a first test. If you already have a moq-lite-compatible relay running, whether self-hosted or a third-party service like Cloudflare’s MoQ CDN edge, you can point the plugin at that instead. A ready-to-use browser player and publisher page are also included out of the box.

MoQ vs. WebRTC vs. HLS
Feature MoQ WebRTC HLS / DASH
Origin ~2022–present, IETF draft 2011, W3C & IETF standard 2009, RFC 8216+
Latency Sub-second (configurable) Flexible ~0.2–0.5s Ultra-low 3–30 seconds
Architecture Pub/Sub + CDN relay SFU CDN / origin
CDN Cacheable Yes No Yes
Browser Support Chrome, Edge Limited All major browsers Universal All major browsers Universal
Transport QUIC / WebTransport UDP / DTLS-SRTP TCP / HTTP
moq-lite vs. Full IETF moq-transport: Where Things Stand
It is worth being precise about what “MoQ support” means today, because there are two distinct layers to understand.

moq-lite
Deployable Today
A deliberately simplified and forwards-compatible subset of the IETF draft. The philosophy: rather than waiting years for a finalized standard, ship something real today and stay compatible as the spec evolves. moq-lite already interoperates with moq-transport CDNs such as Cloudflare’s MoQ edge.
This is what the AMS MoQ plugin is based on.
IETF moq-transport
Full Specification (In Progress)
Covers full session negotiation, complex track namespacing, subscribe and announce filtering, priority ordering, and delivery preferences. Still an active draft, so it continues to change. Support for moqtail.dev is on our roadmap as it matures.
Think of it like early HTTP: the core ideas were solid and deployable long before the formal RFCs were complete. moq-lite takes the same approach for live media.
How It Works: Architecture Overview
The plugin integrates at the muxer level inside AMS. When a broadcast starts, a MoQMuxer is attached to the stream’s mux pipeline: one for the source quality and one for each adaptive rendition. Encoded frames flow from the encoder directly into the muxer, which forwards them to the embedded relay for fan-out over WebTransport.

Egress (AMS → Browser)
ams-moq-to-browser
Ingest (Browser → AMS)
WebBrowserToAMS
This architecture keeps AMS at the center. Whether you are sending video out to MoQ viewers or pulling video in from a MoQ source, the stream is fully integrated into the AMS ecosystem. The REST API, management console, recording, and all other AMS features apply as normal.

Built-In Browser Player and Publisher
The plugin ships two ready-to-use HTML pages built on the moq-lite TypeScript web components.

AMS MoQ Player
Browser Compatibility Note
The MoQ player currently works on Chromium-based browsers only (Chrome, Edge, Brave, etc.). Safari does not support WebTransport. Firefox has partial WebTransport support but is currently unstable for MoQ playback. We expect this to improve as browser vendors continue adopting the WebTransport specification.
The player page (play.html) is built on the web component and requires no JavaScript beyond what is bundled. Key capabilities:

Dual Render Mode
Auto-selects between WebCodecs (canvas-based, lowest latency) and MSE (video element, broader compatibility), or can be forced manually.
Relay URL Probing
Automatically tries multiple relay URL candidates and connects to the first that responds. Useful when the relay is on a different port or behind a proxy.
Live Debug Panel
Real-time FPS, buffer size, stall events, latency, codec in use, and video bytes received. Invaluable during integration and testing.
AMS MoQ Publisher
The publisher page (publish.html) is built on the web component and allows browser-based publishing directly to the MoQ relay:

Camera & Screen Capture
Capture from camera or screen share with a single click.
Audio & Video Controls
Toggle audio mute and video off independently.
Relay URL Probing
Live relay URL probing with per-candidate status indicators.
Supported Codecs
Track Supported Codecs
Video H.264 (AVC) H.265 (HEVC)
Audio AAC Opus
H.264 streams use Annex B SPS/PPS extraction to ensure correct decoder initialization on the receiver side. Codecs outside this list (such as VP8) are not yet supported. Expect this to expand as the MoQ ecosystem matures.

Getting Started
Requirements: Ant Media Server 3.0.0 or later, Linux x86_64, sudo access.

Download MoQPlugin-release.zip and upload it to your server, then run:

1. Unzip the release

unzip MoQPlugin-release.zip

2. Install the plugin and relay binaries

cd MoQ-Plugin
sudo chmod +x install-moq-plugin.sh
sudo ./install-moq-plugin.sh

3. Copy the MoQ player pages to your AMS application

sudo mkdir -p /usr/local/antmedia/webapps/live/moq
sudo cp -r moq-ams-player-build/* /usr/local/antmedia/webapps/live/moq

4. Restart AMS

sudo service antmedia restart
The install script copies MoQPlugin.jar to the plugins directory and extracts the relay binaries. After restart, the play.html and publish.html pages will be available at https://your-server:5443/live/moq/play.html.

Once the server is running, open the publish and play pages in your browser, that’s all it takes!

MoQ Publish Page
publish.html — broadcast over MoQ
MoQ Play Page
play.html — watch with sub-second latency
The standalone MoQ player pages are temporary. MoQ playback and publishing will be built directly into the main Ant Media Server web player in a future release.
A couple of things to check before you open the pages:
HTTPS required on real servers. MoQ uses WebTransport, and browsers only allow it over HTTPS. If your server is on a real domain or IP address, it needs a valid SSL certificate. Localhost is the one exception browsers allow without SSL.
Open port 4443. The embedded MoQ relay listens on UDP/TCP port 4443. If your server is behind a firewall, make sure that port is open to inbound traffic or the browser won’t be able to reach the relay.
Playing Streams via MoQ
Once a stream is live on AMS, viewers can connect directly via the built-in MoQ player or any moq compatible client. Each quality level is available as a separate named track:

Source quality: moq://ams-server-ip:4443/streamId/source
720p rendition: moq://ams-server-ip:4443/streamId/720p
When the player opens, you will see a list of available tracks for the stream. The source track is the original quality as published into AMS. Named renditions like 720p or 480p are adaptive bitrate versions that AMS transcoded on the way through.

About the “publish” track
If you see a publish track in the list, the stream was sent to the relay directly from the browser publisher, without passing through AMS at all. Selecting it plays the stream straight from the MoQ relay, skipping AMS encoding, transcoding, and recording entirely. It is the most direct path with the lowest overhead, though that also means no ABR renditions, no recording, and none of AMS’s pipeline features.
The browser player connects to the relay via WebTransport and subscribes to the preferred track. The relay handles all fan-out, so a single stream can support any number of concurrent viewers without the per-connection overhead that makes WebRTC challenging at scale.

Publishing Streams into AMS via MoQ
AMS also accepts incoming MoQ streams. Beyond the built-in browser publisher, any moq-compatible client can publish directly to the relay and AMS will pick it up as a regular broadcast. Two ways to do it:

Browser
Built-in Publisher Page
Open publish.html from the plugin, enter your relay address, and start publishing from your camera or screen. No setup required.
Any MoQ Client
Direct Relay Publish
Publish directly to the relay URL using any moq-lite-compatible tool:
moq://relay-ip:4443/moq/streamId/publish
Once received, the stream becomes a standard AMS broadcast, ready for recording, transcoding, or re-distribution over WebRTC, HLS, or RTMP.

Configuration
Configuration is optional. The plugin works out of the box with the defaults shown below. To override any value, go to your application’s Settings > Advanced in the AMS web panel and add your MoQ settings nested inside customSettings, under the plugin.moq key:

{
"customSettings": {
"plugin.moq": {
"useEmbeddedRelay": true,
"ingestEnabled": true,
"externalRelayUrl": "https://relay.example.com:9000/moq",
"ingestPollIntervalMs": 2000
}
}
}
Setting Default Description
useEmbeddedRelay true Use the bundled moq-relay on port 4443. Set to false to use an external relay.
ingestEnabled true Enable MoQ ingest via announce polling. Set to false if AMS is publish-only.
externalRelayUrl localhost:4443 URL of the external relay. Only used when useEmbeddedRelay is false.
ingestPollIntervalMs 2000 How often (in ms) to poll the relay’s /announced endpoint for new streams.
When useEmbeddedRelay is true, the relay URL resolves automatically to http://localhost:4443/moq and the external URL setting is ignored.

Frequently Asked Questions
Is the MoQ plugin ready for production use?
The plugin is functional and actively maintained. That said, MoQ as a protocol is still being standardized, so your production readiness depends on your tolerance for an evolving spec. If you are planning a serious integration, we recommend starting with a staging environment and reaching out to us to discuss your use case.

Which browsers support MoQ playback?
MoQ playback requires WebTransport. Chrome and Edge have stable support. Safari does not currently support WebTransport at all. Firefox has partial WebTransport support but is unstable for MoQ playback. We expect browser coverage to improve as the WebTransport specification matures.

Can I use my own external MoQ relay instead of the embedded one?
Yes. Set useEmbeddedRelay: false in the plugin configuration and provide your relay URL via externalRelayUrl. Any moq-compatible relay works, including self-hosted deployments or Cloudflare’s MoQ CDN offering.

Does MoQ replace WebRTC in Ant Media Server?
No, they serve complementary roles. WebRTC remains the right choice for interactive, two-way communication such as video conferencing or ultra-low-latency broadcast (under 200ms). MoQ targets one-to-many broadcast scenarios where you need both sub-second latency and CDN-scale delivery at the same time. Both protocols are supported by AMS and can run side by side on the same server. For a detailed breakdown, see our article WebRTC vs. MoQ — Two Protocols, One Platform Completely Built for Both.

What is moqtail.dev, and when will AMS support it?
moqtail.dev represents the next step in the MoQ ecosystem as the IETF standard matures. We are monitoring its development closely. Support will be added to the AMS MoQ plugin as the library stabilizes and it becomes practical to integrate.

Conclusion
The AMS MoQ plugin is an early but functional step toward the next generation of live streaming infrastructure. By building on moq-lite today, Ant Media Server gives developers a hands-on way to explore what MoQ brings to the table: sub-second latency, CDN-scale fan-out, and a modern browser stack built on WebTransport and WebCodecs. No need to wait for the IETF to wrap up the spec.

We will keep shipping updates as moq-lite evolves and as moqtail.dev support becomes practical to integrate. If you are experimenting with the MoQ plugin or building something on top of it, tell us about it on our community forum or reach out directly.

Ant Media Server v3.0

Akeel Almas — Wed, 13 May 2026 10:20:39 +0000

We’re excited to introduce Ant Media Server v3.0 🚀

This is not just another release. It’s a major step forward that lays the groundwork for the next generation of Ant Media Server (AMS).

Compared to the last version (2.17), this release focuses on three main areas:

Cleaning up the code base for the future
Adding new capabilities and plugins for modern streaming workflows
Improving security and stability
Table of Contents
Getting Ready for the Future
New Streaming Capabilities
New Plugins
MoQ Plugin
AI Plugin
Partner Plugins
Security & Stability Improvements
Conclusion
Getting Ready for the Future
With v3.0, we removed many deprecated methods and outdated structures to simplify the code base. For API, deprecated methods have already been replaced by more powerful ones. In this release the old and deprecated methods are completely removed.

This makes AMS easier to maintain, easier to extend with plugins, and more stable for long-term development.

Ant Media Server Deprecated Feature Removals
Ant Media Server Deprecated Feature Removals
New Streaming Capabilities
With v3.0 we have some new features on streaming. Some of these extensions are involved in the code base. Also some new features are implemented in new Plugins as an extension of Ant Media Server.

Let’s start with the new features developed in the code base.

Introducing AV1 Codec: AV1 codec is one of the new features now supported in AMS. AV1 codec promises better compression, lower bandwidth usage, and more future-proof streaming.
Re-streaming via SRT: SRT workflows are improved with re-stream support. This helps distribute streams across multiple endpoints not only with RTMP and also through SRT.
Improvement on VoD Streaming: We also improved Video-on-Demand (VOD) streaming. You can now add metadata when uploading VOD via REST and search VODs using metadata. This makes content management more flexible.
Enhancements on LL-HLS: Low-Latency HLS continues to improve with LL-HLS cluster play support. Also we are happy to include that Ant Media Server web player can now play LL-HLS streams. This means you won’t need any other player while switching between play protocols.
Security Improvements: We also had additions for security improvements, including the Strict-Transport-Security (HSTS) header and fixes for known vulnerabilities.
You can reach the whole list of the new implementations in v3.0 here.

New Plugins
Beside the features listed above, we also introduced great features with the new plugins to extend streaming capabilities. As a good news we have some plugins from Ant Media Server community. Also more plugins are on the way and coming soon.

MoQ Plugin
Media over QUIC (MoQ) is a promising new real-time streaming protocol. Ant Media Server now supports it with MoQ plugin. You can read this blogpost to understand how to install it on AMS and use it.

moq-hero
AI Plugin
This plugin acts as a bridge between Ant Media Server and mainly Python modules that process video frames. It streams video frames from an ongoing stream to external Python modules, enabling use cases like object detection and other AI-based processing to be handled by external AI workflows.

Ant Media Server and AI
Ant Media Server and AI
Partner Plugins
Besides these plugins we have new plugins listed in Ant Media Server marketplace which are created by Partners.

Scribe: Automatic subtitling for live video streams using speech-to-text technology. More details are here.

Scotty: Easy Server-Side Ad Insertion to seamlessly deliver ads within live and on-demand streams without interrupting playback. More details are here.

Security & Stability Improvements
Indeed, we haven’t inserted new features only. Besides them we focused heavily on making the system more stable and predictable. This release also includes various bug fixes and security improvements. You can reach them here.

Conclusion
As we announced before we plan to release a new version each quarter. This time it was a major release v3.0. With v3.0, we continue improving the Ant Media Server experience by simplifying the code base, adding support for new codecs and protocols, improving APIs and SDKs, and expanding the plugin ecosystem. We will come with a new minor release with some new good improvements. Please keep following us.

MoQ Support Is Now Available in Ant Media Server

Akeel Almas — Wed, 29 Apr 2026 10:19:15 +0000

Ant Media Server now supports Media over QUIC (MoQ), a next-gen streaming protocol built on QUIC and WebTransport. It enables sub-second latency with CDN-scale delivery, combining the best of WebRTC and HLS.

With the new MoQ plugin, you can:

Deliver live streams to browsers with ultra-low latency
Ingest streams from MoQ-compatible sources
Scale efficiently using relay-based architecture
Use built-in browser player and publisher (no extra setup)

MoQ is still evolving, but Ant Media provides early support via moq-lite, allowing developers to start experimenting today while staying aligned with future standards.

👉 Read full article: https://antmedia.io/moq-support-now-available-in-ant-media-server/

What is Simulcasting in Live Streaming?

Akeel Almas — Wed, 15 Apr 2026 10:36:36 +0000

Simulcasting

Owais
Author
Apr 9, 2026
12 min read
You’ve got one stream. Your audience is on YouTube, Facebook, Twitch, and LinkedIn — all at the same time. Simulcasting lets you reach all of them simultaneously from a single broadcast, without running multiple encoders or creating separate content for each platform.

That’s the short version. Here’s everything else you need to know — from how the architecture works under the hood to exactly how to set it up with Ant Media Server.

Table of Contents
What is Simulcasting and How Does It Differ from Standard Streaming?
How Does Simulcast Architecture Work Technically?
What Are the 5 Key Benefits of Simulcasting?
What is the Difference Between Simulcasting, Multicasting, and Adaptive Bitrate Streaming?
How Do You Set Up Simulcasting with Ant Media Server?
What are the Supported Simulcast Destination Types in Ant Media Server?
What are the Bandwidth and Encoding Requirements for Simulcasting?
Frequently Asked Questions
Conclusion
What is Simulcasting and How Does It Differ from Standard Streaming?
Simulcasting is the simultaneous transmission of the same encoded video stream to 2 or more destination platforms from a single ingest point. A media server takes that one incoming stream, duplicates it, and pushes independent copies to every platform you’ve configured — all at the same time.

Standard streaming sends one stream to one platform. Simulcasting sends that same stream to N platforms in parallel. The key thing: your encoder doesn’t do the heavy lifting here. It pushes once to the media server. The media server handles everything else.

The term comes from “simultaneous broadcast” — a concept that goes back to radio in the 1920s. The BBC first simulcast a live symphony performance over both medium and long-wave frequencies in 1926. Today, it describes real-time multi-platform distribution to destinations like YouTube Live, Facebook Live, Twitch, and any RTMP-compatible endpoint including custom servers and CDN ingest points.

The critical difference from standard streaming: your encoder (OBS, Wirecast, vMix) sends one RTMP stream to the media server’s ingest endpoint. The media server — not the encoder — duplicates and forwards to each destination. Your encoder’s CPU and upload bandwidth don’t scale with the number of platforms you’re targeting.

How Does Simulcast Architecture Work Technically?
Simulcast architecture in Ant Media Server runs across 4 sequential stages: ingest, optional transcoding, stream duplication, and parallel forwarding. Here’s what actually happens at each stage.

Stage 1 — RTMP Ingest
Your encoder publishes a single H.264 or H.265 stream to Ant Media Server’s RTMP ingest endpoint: rtmp://[server-ip]/LiveApp/[streamId]. The server accepts the stream on port 1935 and buffers the incoming encoded bitstream.

Stage 2 — Optional Transcoding
If adaptive bitrate transcoding is enabled, Ant Media Server decodes the ingest stream and re-encodes it at multiple quality levels (1080p, 720p, 480p). For simulcasting to social platforms, the original bitstream is typically passed through without re-encoding — this keeps CPU overhead low and preserves your encoder-side quality settings.

Stage 3 — Stream Duplication
Ant Media Server creates parallel stream copies in memory. Each copy is an independent data pathway with its own buffer, connection state, and destination RTMP URL. Duplication happens at the application layer — the server doesn’t retransmit the ingest stream from your encoder. It forwards from its own buffer to each destination.

Stage 4 — Parallel RTMP Forwarding
Each duplicated stream is pushed simultaneously to its configured destination using that platform’s RTMP ingest URL and stream key. Ant Media Server maintains an independent TCP connection to each platform, handles reconnection on failure, and monitors each output stream’s connection state and bitrate.

A failure on one destination doesn’t interrupt the others. Your YouTube stream stays live even if Facebook’s RTMP ingest goes down.

One thing to plan for: a 5 Mbps 1080p30 ingest stream requires 5 Mbps × N Mbps of outbound bandwidth from the Ant Media Server instance, where N equals the number of simultaneous destination streams. A 3-platform simulcast at 5 Mbps per destination needs 15 Mbps of sustained outbound throughput from the server.

What Are the 5 Key Benefits of Simulcasting?
Simulcasting isn’t just a nice-to-have for large broadcasters. These 5 advantages apply whether you’re running a startup webinar or a stadium live event.

Multiply Your Audience Reach Without Extra Production Overhead
One encoder session, one camera setup, one production workflow — distributed to YouTube, Facebook, LinkedIn, and Twitch at the same time. Production cost stays constant while your addressable viewer count scales with every platform you add.
Activate Multiple Platform Algorithms Simultaneously
Each destination platform registers an independent live stream event. That triggers its notification system and live content feed ranking for that platform’s subscriber base. A 3-platform simulcast activates 3 separate recommendation algorithms from a single broadcast.
Meet Your Audience Where They Already Are
Your audience has strong platform preferences — gaming audiences cluster on Twitch, professionals prefer LinkedIn Live, casual viewers default to YouTube — and committing to one platform means losing everyone else. Understanding live streaming platform reach shows that simulcasting eliminates that segmentation loss entirely, letting a single broadcast event activate every platform’s notification and recommendation system simultaneously.
Build Resilient Broadcast Delivery
Single-platform streaming has no fallback path — if that platform’s RTMP ingest failure takes your entire broadcast offline. Simulcasting maintains parallel TCP connections to each destination independently, so one disconnection leaves every other output stream untouched. You get inherent redundancy across output paths without any extra infrastructure.
Collect Cross-Platform Analytics From One Event
Every destination platform generates independent viewer count, engagement, and retention data for the same broadcast event — parallel performance datasets from a single production workflow that live streaming analytics simply cannot provide from single-platform streaming alone. Cross-platform data reveals which audiences engage longest, which platforms drive the highest interaction rate, and where to concentrate future broadcast investment.

What is the Difference Between Simulcasting, Multicasting, and Adaptive Bitrate Streaming?
These 3 methods operate at different layers of the streaming stack. They’re often confused — here’s how they actually differ across 5 technical dimensions.

Dimension Simulcasting Multicasting Adaptive Bitrate (ABR)
Network layer Application (RTMP/HTTP) Network (IP multicast) Application (HLS/DASH)
Stream copies N copies pushed to N platforms 1 copy to N receivers at network level 1 stream per quality tier
Destination YouTube, Facebook, Twitch, any RTMP endpoint Private LAN, IPTV, enterprise CDN delivery to individual viewers
Bandwidth Scales linearly with destination count Constant regardless of receivers Scales with viewer count × bitrate
Primary use case Multi-platform social distribution Campus/corporate IPTV Adaptive viewer delivery
The important thing: simulcasting and adaptive bitrate streaming are complementary, not competing. Ant Media Server can simultaneously simulcast to YouTube Live while serving HLS adaptive bitrate streams to viewers on your own website — both running from the same single ingest stream.

How Do You Set Up Simulcasting with Ant Media Server?
Install and configure Ant Media Server. Deploy on Ubuntu 22.04 LTS using the one-line installation script or deploy from AWS Marketplace, Azure Marketplace, or Google Cloud Marketplace. Make sure ports 1935 (RTMP), 5080 (HTTP), and 5443 (HTTPS) are open on your instance’s security group or firewall.
Create a live stream in the web panel. Log in to the Ant Media Server web panel at https://[your-domain]:5443. Navigate to the LiveApp application, select “New Live Stream,” and assign a stream ID. Your ingest URL follows the pattern rtmp://[server-address]/LiveApp/[streamId].
Configure RTMP endpoint forwarding. In the stream settings, click the hamburger icon on the right of your stream row, then select Edit RTMP Endpoint. Enter each destination’s RTMP ingest URL and stream key. YouTube Live uses rtmp://a.rtmp.youtube.com/live2/[stream-key]; Facebook Live uses rtmps://live-api-s.facebook.com:443/rtmp/[stream-key]. Click Add RTMP Endpoint for each platform.
Publish the ingest stream. When your encoder goes live, Ant Media Server simultaneously forwards to all configured destination endpoints. For OBS RTMP configuration with Ant Media Server, set the server URL to rtmp://[server-address]/LiveApp and the stream key to your assigned streamId — the same ingest point feeds every simulcast destination from that single connection.
Monitor stream health via REST API (advanced). The REST API endpoint GET /LiveApp/rest/v2/broadcasts/{streamId} returns real-time status for the source stream including connection state and bitrate. To manage RTMP endpoints programmatically, use POST /LiveApp/rest/v2/broadcasts/{streamId}/rtmp-endpoint to add destinations and DELETE to remove them. For the full endpoint reference and authentication setup, see the REST API guide, which covers IP filter configuration, JWT token authentication, and the complete broadcast object schema.
What are the Supported Simulcast Destination Types in Ant Media Server?
Ant Media Server supports simulcast forwarding to any RTMP or RTMPS-compatible destination endpoint. The official docs confirm the following platforms with their specific ingest URL formats:

YouTube Live — rtmp://a.rtmp.youtube.com/live2/[stream-key]
Facebook Live — rtmps://live-api-s.facebook.com:443/rtmp/stream-key
Twitch — [nearest-ingest-endpoint]/stream-key
Periscope — rtmp://de.pscp.tv:80/x/[stream-key]
Any RTMP-compatible platform — including LinkedIn Live, Twitter/X, and other services that provide an RTMP ingest URL and stream key
Custom RTMP servers — any RTMP-compliant ingest endpoint, including other Ant Media Server instances and CDN ingest points
Because Ant Media Server forwards to any RTMP endpoint, you’re not limited to the platforms listed above. If a platform gives you an RTMP URL and stream key, it works as a simulcast destination. This also enables cascaded architectures — forwarding from one Ant Media Server instance to another for multi-hop distribution pipelines.

What are the Bandwidth and Encoding Requirements for Simulcasting?
Simulcast bandwidth requirements scale linearly with destination count multiplied by per-stream bitrate. Planning this correctly before you go live is the most common thing people skip.

A 1080p30 simulcast at 4 Mbps per stream to 4 destinations requires 16 Mbps of sustained outbound bandwidth from the Ant Media Server instance. That’s the primary infrastructure scaling factor — it’s what determines whether you need a larger instance or not. Size your server instance based on outbound bandwidth capacity, not CPU, when running pass-through simulcast (no transcoding).

Here are the encoding specs that work reliably across all major social platform RTMP ingest systems:

Spec Value Why It Matters
Video codec H.264 (Baseline or Main Profile) Universal RTMP ingest compatibility across all social platforms
1080p30 bitrate 4–6 Mbps Meets YouTube Live, Facebook Live, and Twitch quality requirements
720p30 bitrate 2.5–4 Mbps Reliable delivery with lower server bandwidth overhead
Audio codec AAC-LC, 128 kbps stereo Required by YouTube and Facebook RTMP ingest (YouTube rejects streams without audio)
Keyframe interval 2 seconds (every 60 frames at 30fps) Required by most social platform RTMP ingest systems for segment alignment
The wrong audio codec selection causes immediate rejection at the platform ingest level — which is why verifying encoder audio settings before going live with a simulcast is a non-negotiable pre-flight step. AAC-LC at 128 kbps stereo is the standard requirement across YouTube and Facebook RTMP ingest systems.

CPU overhead in pass-through mode is low. When simulcasting without transcoding, Ant Media Server forwards the incoming encoded bitstream without decode/re-encode. CPU load scales primarily with the number of TCP connections managed, not video resolution. The key resource to monitor and size for is outbound bandwidth — add the per-stream bitrate for every destination you’re targeting.

Frequently Asked Questions
What is simulcasting in live streaming?
Simulcasting is the simultaneous transmission of one live stream to multiple destination platforms — such as YouTube, Facebook, and Twitch — from a single RTMP ingest point. A media server duplicates the ingest stream and pushes independent copies to each configured RTMP endpoint in parallel.

Does simulcasting require a separate encoder for each platform?
No. You need one encoder publishing to one media server ingest endpoint. The media server handles duplication and parallel forwarding to all destination platforms. Adding destinations increases server outbound bandwidth, not encoder load or production complexity.

How many platforms does Ant Media Server simulcast to simultaneously?
Ant Media Server supports simulcasting to multiple RTMP and RTMPS destination endpoints from a single ingest stream. The practical limit is your server’s available outbound bandwidth — each destination consumes bandwidth equal to the forwarded stream’s bitrate.

What is the difference between simulcasting and adaptive bitrate streaming?
Simulcasting forwards the same encoded stream to multiple platform destinations simultaneously. Adaptive bitrate streaming delivers multiple quality tiers of a stream to individual viewers, where each viewer’s player selects the appropriate bitrate based on network conditions. Both work from a single Ant Media Server ingest stream and run in parallel.

What encoder settings work best for simulcasting?
H.264 video at 4–6 Mbps for 1080p30, AAC-LC audio at 128 kbps, and a 2-second keyframe interval. These settings satisfy the ingest requirements of YouTube Live, Facebook Live, Twitch, and other RTMP-compatible platforms simultaneously. In OBS, use the zerolatency tune setting for x264 or enable Low Latency mode for NVENC to minimize encoder-side delay.

Does Ant Media Server support simulcasting via REST API?
Yes. The REST API provides programmatic control over simulcast RTMP endpoint management. Use POST /LiveApp/rest/v2/broadcasts/{streamId}/rtmp-endpoint to add a destination and DELETE /LiveApp/rest/v2/broadcasts/{streamId}/rtmp-endpoint?endpointServiceId={dataId} to remove one. The GET /LiveApp/rest/v2/broadcasts/{streamId} endpoint returns the broadcast object with current connection state and bitrate.

Is simulcasting the same as multistreaming?
Yes — same outcome, different framing. Simulcasting is the technical method (server-side stream duplication and parallel RTMP forwarding). Multistreaming is the same workflow described in product interfaces and marketing. They refer to the same thing.

Conclusion
Simulcasting routes a single RTMP ingest stream to multiple simultaneous platform destinations through server-side duplication and parallel forwarding — one production workflow reaches YouTube Live, Facebook Live, Twitch, and any RTMP-compatible endpoint at the same time. No extra encoders. No extra production overhead.

Ant Media Server handles ingest, optional transcoding, stream duplication, and parallel RTMP forwarding — with per-destination connection monitoring and full REST API control over every endpoint. In pass-through mode, CPU overhead scales with TCP connection count, not resolution — the resource to size for is outbound bandwidth per destination stream.

You can validate the complete simulcast forwarding pipeline — including RTMP endpoint configuration, REST API management, and adaptive bitrate integration — during a 14-day free trial of Ant Media Server’s simulcast streaming deployment.

WebRTC vs. MoQ — Two Protocols, One Platform Completely Built for Both

Akeel Almas — Wed, 08 Apr 2026 10:51:40 +0000

Two powerful protocols. One streaming platform built for both. Lets focus on what happens today and what’s waiting for us in the future as Ant Media Server perspective.

WebRTC vs. MoQ — Two Protocols, One Platform Built for Both

The live streaming world is buzzing about Media over QUIC (MoQ) — a new IETF-standard protocol that promises to combine the scalability of CDN-based streaming with the sub-second latency as we used to associate with WebRTC only so far. At Ant Media Server, we’ve built our platform around WebRTC since day one as known globally.

So the question we get asked constantly is: Should you be worried? Is WebRTC dead?

The short answer: No. But MoQ is genuinely exciting — and understanding the difference between the two is critical to making smart infrastructure decisions now and also for future.

Two Protocols, Two Philosophies

WebRTC and MoQ weren’t designed for the same problem. They emerged from different eras, different constraints, and different visions of what the real-time web should look like.

WebRTC
Web Real-Time Communication
Born in 2011
Standardized by W3C & IETF, shipped in Chrome in 2012
~0.2–0.5s latency
True sub-second, ideal for interactive apps
SFU Architecture
Server-side Selective Forwarding Units for scalability
Universal browser support
Chrome, Safari, Firefox, Edge — no plugins needed
Transport: UDP / DTLS-SRTP
Built on RTP, approximately 20 referenced standards
MoQ
Media over QUIC
Emerging standard, ~2022–present
IETF working group, still in active development
Sub-second to near-real-time
Configurable latency from ultra-low to VOD-grade
Pub/Sub + CDN Relay Architecture
Relays fan out live media with structured tracks
Chrome & Edge only (2026)
Safari iOS WebTransport support is on the way
Transport: QUIC / WebTransport
Built on HTTP/3, no RTP dependency

WebRTC: Where Ant Media Focuses Today

Ant Media Server was built around WebRTC — and for good reason. WebRTC delivers sub-0.5 second latency across every major browser on the planet without requiring a plugin, app download, or special configuration from your end users. For use cases where responsiveness is existential — live auctions, telehealth consultations, remote drone monitoring, interactive sports betting — there is simply no better option available at production scale today.

Our SFU-based architecture means viewer connections are handled efficiently: the origin node accepts and transcodes incoming streams, while edge nodes play them out. This scales from a few person virtual classroom to a global live event with tens of thousands of concurrent viewers — and it does so on infrastructure that auto-scales on AWS, Azure, GCP, or your own on-premise cluster via Kubernetes.

Where WebRTC Wins

Telehealth & Remote Consultation
HIPAA-compliant, real-time patient-provider video with sub-500ms responsiveness. Latency matters when a doctor needs to notice a patient’s reaction.
Live Auctions & Bidding
Fairness depends on all bidders seeing the same moment simultaneously. Any latency asymmetry is a legal and commercial liability.
Interactive Gaming & Betting
Engagement and revenue in real-time gaming require immediate feedback loops. WebRTC delivers the interactivity that keeps users in the moment.
Surveillance & IoT Monitoring
Real-time CCTV and IP camera feeds benefit from WebRTC’s encrypted, browser-native delivery without buffering delays or plugins.

The Honest Limitations

WebRTC’s complexity is legendary. The protocol stack references approximately 20 standards, making it genuinely difficult to customize outside the bounds of what browser vendors choose to implement. ICE negotiation, STUN/TURN traversal, and SDP signaling are all layers of complexity that sit between you and “just streaming video.” At Ant Media, we abstract most of this — but it’s worth being honest that at true internet-scale one-to-many streaming, WebRTC’s architecture requires significant investment to remain cost-efficient.

WebRTC also has no native concept of CDN-friendly relay architectures. It scales through SFUs and clustering which means infrastructure costs grow with your viewer count in ways that pure CDN-used protocols avoid.

MoQ: The Architecture That Fixes the Middle Ground

Media over QUIC is the most thoughtful attempt yet to bridge the long-standing gap between two worlds: the cost efficiency and CDN-scalability of HLS, and the near-zero latency that WebRTC enables. MoQ is built on QUIC — the same transport layer behind HTTP/3 — which eliminates TCP’s head-of-line blocking, handles connection migration gracefully.

The key innovation in MoQ is its publish/subscribe model built around “tracks” — linear flows of media data (video, audio, captions, metadata) that relays can cache and fan out at the live edge. Unlike WebRTC, which requires a full SFU session per viewer, MoQ’s relay architecture lets CDN nodes participate natively. That’s why giant companies like YouTube are paying attention: MoQ lets existing CDN infrastructure be upgraded rather than replaced.

MoQ’s goal is to give you WebRTC-like interactivity and HLS-like scalability in a single protocol. Sub-second join times + internet-scale fan-out without maintaining thousands of individual real-time sessions.

Where MoQ Shines (When Ready)

Large-Scale Live Events
Concerts, sports broadcasts, and political events where you need sub-second latency for a million simultaneous viewers — a CDN relay model makes this economical.
Hybrid Live + VOD Platforms
A single protocol handling live streaming and on-demand playback means dramatically simpler architecture and unified infrastructure costs.
Next-Gen CDN Integration
MoQ’s HTTP/3 compatibility means CDNs can extend their existing networks rather than replace them wholesale.

The Honest Limitations

MoQ is genuinely exciting — but it is not production-ready today, and the numbers back that up. As of late 2025, WebTransport (which MoQ depends on in browsers) represents a fraction of a percent of web page loads, versus WebRTC’s stable ~0.35%. Chrome metrics show brief experimental spikes followed by drop-offs.

Safari on iOS was a significant blocker until it was recently (a week ago) announced that WebTransport is supported with Safari iOS 26.4 , may help removing fallback implementations that add complexity. Some networks still block UDP traffic. And the MoQ specification itself, while advancing rapidly through IETF, is still evolving — meaning production deployments today may carry interoperability risk.

Feature Comparison

Dimension WebRTC MoQ (Media over QUIC)
Latency 0.2–0.5s Ultra-low Configurable: sub-1s to multi-second Flexible
Transport Layer UDP / DTLS-SRTP / RTP QUIC / HTTP/3 / WebTransport
Browser Support All major browsers Universal Chrome, Edge, Safari (not verified) Limited
CDN Compatibility Requires SFU infrastructure Native HTTP/3 CDN relay support Advantage
Scalability Model SFU clustering, session per viewer Pub/sub relay with CDN fan-out
Protocol Complexity ~20 referenced standards Simpler stack, still maturing
Production Readiness Battle-tested since 2012 Emerging — experimental in 2026
Codec Flexibility Browser-bound (VP8/VP9, H.264, AV1) Protocol-agnostic, codec-flexible Advantage
VOD / Live Unification Separate solutions required Single protocol covers both Future advantage
Standardization W3C + IETF — fully standardized IETF working group — in progress
Ant Media Support Full production support On the roadmap

Where Ant Media Is Positioned: Protocol-Agnostic Pragmatism

Ant Media Server has always been protocol-pragmatic. We started with RTMP and WebRTC, layered in SRT, RTSP, HLS, LL-HLS, CMAF, WHIP/WHEP — because the right protocol depends on the use case, not industry fashion cycles.

Our position on WebRTC vs MoQ mirrors what the most credible voices in the streaming space have concluded: these protocols are not competitors — they are complements. WebRTC is the definitive answer for interactive, browser-native, sub-500ms experiences. MoQ is the most architecturally elegant answer for the future of one-to-many streaming at internet scale with CDN economics.

The industry consensus forming around a hybrid workflow makes intuitive sense: WebRTC for browser-based contribution and ingest, with MoQ as the delivery layer when it matures. This is exactly the kind of architecture Ant Media Server is designed to support — accepting streams over any protocol and delivering them over whatever transport best fits the viewer context.

What This Means for Ant Media Users

Today: build on WebRTC with confidence. Our SFU-based clustering, adaptive bitrate engine, auto-scaling on major clouds or on premise, and ~0.5s latency guarantee are production-proven. When MoQ achieves production maturity, Ant Media’s multi-protocol architecture means you add it as a delivery option — not a platform migration.

How Ant Media Approach: Don’t Choose. Prepare for Both.

If you need to build something today — a telehealth platform, a live auction, a drone monitoring system, an interactive sports stream — build it on WebRTC. It’s proven, universally supported, and with Ant Media Server, it scales gracefully from prototype to production without infrastructure dependencies.

If you’re designing a platform for 2028 and beyond — especially one where CDN economics and massive concurrent audiences matter — keep a close eye on MoQ. The fundamentals are solid. The IETF momentum is real. The giant companies are all investing. When cross-browser support closes, MoQ will be ready for the architectures that WebRTC was never designed for.

At Ant Media, our strategy is simple: the future of streaming is to have multi-protocol capability in one platform, and your infrastructure should be too. We’re watching MoQ closely, supporting WHIP/WHEP as the bridge between today and tomorrow, and building the platform that lets you change your delivery layer without changing your application.

To demonstrate our commitment to our users, we’ve decided to showcase how MoQ works and performs compared to other protocols at NAB Show, starting April 19, 2026, at Booth 3318 in Las Vegas. We invite you to join us and experience it firsthand.

Pick the right tool for the right job — and build on infrastructure flexible enough to evolve with it.

Versatile Video Coding (VVC): H.266 Codec Guide for Streaming

Akeel Almas — Wed, 25 Mar 2026 09:26:40 +0000

Streaming platforms transmit over 1 billion hours of video daily, and codec efficiency determines the bandwidth cost of every single hour. A platform serving 10,000 concurrent 4K streams consumes approximately 120 Gbps with H.265 (HEVC) compression. Versatile Video Coding (VVC), also known as H.266, cuts that figure to approximately 60–70 Gbps at equivalent visual quality—a 40–50% bitrate reduction that translates directly into lower CDN costs, reduced storage consumption, and higher-quality delivery on bandwidth-constrained networks.

VVC arrived as the official successor to HEVC when the Joint Video Experts Team (JVET) finalized the specification on July 6, 2020. Six years later, VVC adoption follows a split trajectory: broadcast and connected TV ecosystems adopt VVC through hardware decode mandates from the DVB Project and ATSC 3.0, while browser-based streaming remains locked to H.264, H.265, and the royalty-free AV1 codec due to patent licensing barriers. Streaming platform operators face a practical question—where does VVC fit alongside existing codecs, and when does the compression advantage justify integration into their delivery pipeline?

This guide examines VVC’s 6 compression innovations, compares performance against HEVC, AV1, and H.264 with specific bitrate figures, maps hardware and software support as of March 2026, breaks down the patent licensing landscape, identifies the 5 streaming use cases where VVC delivers measurable ROI, and explains how multi-codec delivery architectures—like those built on Ant Media Server—position streaming operators to adopt VVC incrementally as device support expands.

Table of Contents
What is H.266/VVC (Versatile Video Coding)?
What are the 6 Core Technical Innovations in VVC?
How Does VVC Compare to HEVC, AV1, and H.264?
What Hardware and Software Support VVC in 2026?
What are the VVC Patent and Licensing Requirements?
Which 5 Streaming Use Cases Benefit from VVC?
How Does Multi-Codec Delivery Prepare for VVC Adoption?
Frequently Asked Questions
Conclusion
What is H.266/VVC (Versatile Video Coding)?
Versatile Video Coding
H.266, formally designated Versatile Video Coding (VVC), is a video compression standard that achieves approximately 50% bitrate reduction at equivalent perceptual quality compared to HEVC (H.265). The Joint Video Experts Team (JVET)—a collaboration between ITU-T Video Coding Experts Group (VCEG) and ISO/IEC Moving Picture Experts Group (MPEG)—finalized VVC on July 6, 2020, under designations ITU-T H.266 and ISO/IEC 23090-3 (MPEG-I Part 3).

VVC targets the compression demands of 4K, 8K, HDR, 360-degree immersive, and screen content video. The codec supports YCbCr 4:4:4, 4:2:2, and 4:2:0 chroma subsampling at 8–10 bit depth in the Main 10 profile, with 12–16 bit depth added in the 2022 second edition. Frame rate support spans 0 to 120 Hz, BT.2100 wide color gamut, and HDR peak brightness values of 1,000, 4,000, and 10,000 nits. VVC supports resolutions from very low resolution up to 16K as well as 360-degree video formats.

Fraunhofer Heinrich Hertz Institute (HHI) in Germany contributed core encoding tools and announced the standard in July 2020. The development timeline began in October 2015 when MPEG and VCEG formed JVET, issued a formal Call for Proposals in October 2017, produced the first working draft in April 2018, and demonstrated a preliminary implementation at IBC 2018 showing 40% compression gain over HEVC. For streaming platforms already delivering content with H.264 and H.265—the two codecs that Ant Media Server currently supports for WebRTC, HLS, LL-HLS, and DASH/CMAF output—VVC represents the next codec generation entering production pipelines as hardware decode adoption expands.

What are the 6 Core Technical Innovations in VVC?
VVC introduces 6 architectural innovations that collectively produce its 50% compression efficiency gain over HEVC. These innovations span block partitioning, motion prediction, transform coding, and in-loop filtering stages of the encoding pipeline.

What is Multi-Type Tree (MTT) Partitioning?
Multi-Type Tree partitioning replaces HEVC’s fixed quadtree structure with a flexible system supporting binary and ternary splits in horizontal and vertical directions. HEVC limited Coding Tree Units (CTUs) to square blocks between 4×4 and 64×64 pixels using quadtree-only partitioning. VVC extends CTU sizes to 128×128 pixels and permits non-square rectangular blocks through nested quadtree, binary tree, and ternary tree splits. MTT enables precise alignment of block boundaries to object edges, motion boundaries, and texture transitions in source video.

How Does Affine Motion Compensation Improve Prediction?
Affine motion compensation models rotation, zoom, and shear movements that translational motion vectors cannot represent. VVC implements 4-parameter (similarity) and 6-parameter (affine) motion models. According to Fraunhofer HHI research from the Video Communications and Applications department, affine prediction reduces residual energy by 15–20% for sequences containing camera pan or zoom operations compared to translational-only prediction.

What Role Does Adaptive Loop Filtering (ALF) Play?
Adaptive Loop Filtering applies diamond-shaped Wiener filters at the block boundary level to reduce compression artifacts. ALF operates as the final stage in VVC’s three-stage in-loop filtering pipeline, following the deblocking filter and sample adaptive offset (SAO) filter. The filter coefficients adapt per CTU row, preserving texture detail in high-complexity regions while smoothing flat areas.

What are Geometric Partition Modes?
Geometric partition modes divide prediction blocks along diagonal or angular boundaries instead of axis-aligned splits. VVC defines 64 geometric partition angles, each producing two triangular or trapezoidal sub-regions with independent motion vectors. Geometric partitions improve compression for scenes with diagonal edges, oblique object boundaries, and non-rectangular motion patterns that axis-aligned partitions encode inefficiently.

How Does Subpicture Streaming Work?
Subpicture streaming divides a VVC bitstream into independently decodable spatial regions. Each subpicture functions as a self-contained coding unit with its own motion vector constraints and loop filter boundaries. Subpicture support enables viewport-dependent 360-degree video delivery, where a player decodes only the visible viewport subpictures rather than the full spherical frame, reducing decode computational load for 8K 360-degree content by 60–75%.

What is VVC’s Advanced Entropy Coding System?
VVC’s Context-Adaptive Binary Arithmetic Coding (CABAC) engine extends HEVC’s entropy coder with larger context models and a multi-hypothesis probability update mechanism. The expanded context tables for transform coefficient coding contribute 3–5% of VVC’s total bitrate savings, with the largest gains appearing at high bitrates where coefficient distribution modeling dominates compression performance.

How Does VVC Compare to HEVC, AV1, and H.264?
The following 4-codec comparison table presents 7 attributes across H.264 (AVC), H.265 (HEVC), AV1, and H.266 (VVC), covering compression efficiency, licensing, browser support, hardware decode availability, encoding complexity, approximate 4K bitrate, and primary deployment targets in 2026.

Attribute H.264 (AVC) H.265 (HEVC) AV1 H.266 (VVC)
Compression vs H.264 Baseline ~35–40% better ~45–50% better ~50–55% better
Licensing Royalties (MPEG LA) Royalties (3 pools) Royalty-free (AOMedia) Patent pools (Access Advance, Via-LA)
Browser Support Full (all browsers) Limited (Safari, Edge) Strong (Chrome, Firefox, Edge) None (experimental only)
Hardware Decode Universal Universal (4K+ TVs) Growing (Intel, Apple, Qualcomm) Emerging (Intel Lunar Lake, MediaTek Pentonic)
Encoding Complexity 1x baseline ~2–4x AVC ~5–7x AVC ~8–10x AVC
4K Bitrate (approx.) 15–20 Mbps 8–12 Mbps 6–9 Mbps 5–8 Mbps
Primary Use (2026) Universal fallback 4K OTT, Apple ecosystem Web streaming, mobile UHD broadcast, CTV, 8K
VVC achieves the highest compression efficiency of any production codec, delivering 50–55% bitrate reduction over H.264 and approximately 10–15% improvement over AV1 at 4K resolution based on Fraunhofer HHI’s VVenC benchmarks. The VVenC encoder delivered a 39% efficiency gain over x265 (HEVC) in Streaming Media Magazine testing, though the advantage over AV1 narrowed to approximately 11% in those tests. AV1 maintains a deployment advantage in browser-based streaming due to royalty-free licensing and native Chrome, Firefox, and Edge support. VVC dominates in broadcast and connected TV deployments where hardware decode chipsets provide native playback. Ant Media Server currently supports H.264 and H.265 codecs for WebRTC, HLS, LL-HLS, and DASH/CMAF delivery with VP8 available for WebRTC—the multi-protocol architecture that extends to additional codec support as encoder libraries mature.

What Hardware and Software Support VVC in 2026?
Hardware VVC decode reached a milestone in September 2024 when Intel’s Lunar Lake processors (Core Ultra series) shipped with Xe2 graphics featuring native VVC decode up to 8K60. Intel became the first chipmaker to implement VVC hardware decoding, ahead of NVIDIA and AMD. MediaTek’s Pentonic 800 and 700 chipsets, powering 2024–2025 smart TVs from Samsung, LG, and Sony, include VVC hardware decode capability through dedicated decoder silicon. Qualcomm’s Snapdragon 8 Elite mobile SoC added VVC decode for Android flagship devices.

On the software encoding side, Fraunhofer HHI’s open-source VVenC encoder reached version 1.14 in January 2026, delivering speedups between 20x and 2,400x over the VTM reference software depending on the preset selected. VVenC provides 5 encoding presets (faster, fast, medium, slow, slower) and scales to 32 CPU threads with frame-level parallelization. The companion VVdeC decoder is fully compliant with VVC Main 10 profile and scales across 30+ threads. FFmpeg integrates VVC encoding and decoding through experimental patches from Fraunhofer. The uvg266 encoder from the University of Tampere offers an alternative optimized for real-time encoding, and together with uvgRTP and OpenVVC, provides a complete end-to-end pipeline for live 4K30p VVC intra coding and streaming.

Browser support for VVC remains absent across all major browsers as of March 2026. Chrome, Firefox, Edge, and Safari provide no native VVC decode. According to Rethink Research analysis, VVC has seen almost no commercial uptake in web-based streaming—a trajectory the analyst describes as having deviated significantly from historical codec adoption norms, primarily to AV1’s benefit. The DVB Project formally added VVC to its core broadcast specification in February 2022, making it the first standards body to include a next-generation video codec in its media delivery specification. Future DVB-compliant set-top boxes and smart TVs in Europe, Australia, and affiliated regions are required to support VVC hardware decoding. ATSC 3.0 (NextGen TV) in North America also includes VVC as a supported codec.

What are the VVC Patent and Licensing Requirements?
VVC operates under royalty-bearing licensing, unlike royalty-free AV1. Two primary patent pools govern VVC: Access Advance (fees published April 2021) and Via-LA (formerly MPEG LA, fees published January 2022). In December 2025, Access Advance acquired Via-LA’s HEVC and VVC patent pools, consolidating two pools under one administrator—though this acquisition does not resolve the broader licensing fragmentation.

Multiple essential patent holders remain outside both pools as of March 2026: Apple, Broadcom, Canon, Ericsson, Fraunhofer, Google, Huawei, Intel, InterDigital, LG, Microsoft, Nokia, Oppo, Qualcomm, Samsung, Sharp, and Sony. The fragmented patent landscape creates licensing uncertainty for VVC adopters, mirroring the challenges that slowed HEVC adoption after its 2013 finalization. The Media Coding Industry Forum (MC-IF) was founded to reduce licensing risks, but MC-IF has no authority over the standardization process or patent pool terms.

The licensing complexity directly affects VVC’s competitive position against AV1. Alliance for Open Media (AOMedia) members—including Google, Apple, Amazon, Microsoft, Netflix, Intel, Meta, and Samsung—developed AV1 with explicit royalty-free licensing. Browser vendors who are AOMedia members have no commercial incentive to implement VVC decode, repeating the pattern that limited HEVC to approximately 18% browser compatibility according to CanIUse data despite over a decade of availability.

Which 5 Streaming Use Cases Benefit from VVC?
VVC delivers measurable advantages in 5 streaming deployment categories where bandwidth efficiency at high resolution produces direct cost or quality improvements.

4K and 8K broadcast delivery represents VVC’s strongest deployment category. A 4K HEVC stream at 12 Mbps drops to approximately 6–7 Mbps with VVC at equivalent VMAF quality scores. For broadcast operators delivering hundreds of simultaneous 4K channels, VVC reduces satellite transponder and terrestrial multiplex bandwidth requirements by 40–50%. The DVB Project’s specification mandate ensures hardware decode availability in next-generation European broadcast receivers.

Connected TV and set-top box OTT platforms benefit from VVC in controlled device environments where MediaTek Pentonic and Intel-based chipsets guarantee hardware decode. Premium HDR10+ or Dolby Vision content at 4K achieves 35–45% CDN bandwidth savings compared to HEVC delivery, with VVC content delivered via DASH/CMAF to CTV applications.

360-degree and immersive video applications leverage VVC’s subpicture streaming capability. A full 8K equirectangular 360-degree stream at 80–100 Mbps in HEVC reduces to 40–55 Mbps with VVC, and viewport-dependent subpicture delivery further reduces per-viewer bandwidth to 15–25 Mbps by decoding only visible viewport regions.

UHD archival and VOD libraries achieve 45–50% storage reduction when transcoding HEVC masters to VVC. A 100 TB UHD library compressed in HEVC reduces to approximately 50–55 TB in VVC, producing significant long-term storage infrastructure savings for content operators with large back-catalogs.

Low-bandwidth mobile delivery in emerging markets enables HD-quality playback on 2–3 Mbps connections that previously supported only SD resolution with HEVC encoding. VVC’s compression advantage at low bitrates opens HD streaming to viewers on constrained mobile networks where bandwidth costs per GB remain high.

How Does Multi-Codec Delivery Prepare for VVC Adoption?
VVC’s absent browser support and limited hardware decode footprint in 2026 make single-codec VVC delivery impractical for general audiences. The production deployment model is multi-codec adaptive delivery—serving VVC to hardware-capable devices (smart TVs, set-top boxes, Intel Lunar Lake PCs) while maintaining H.265 and H.264 fallback streams for browsers and older devices. This architecture requires a streaming server capable of multi-codec transcoding, multi-protocol packaging, and adaptive bitrate delivery.

Ant Media Server provides this multi-codec infrastructure today. The server accepts ingest via RTMP, SRT, and WebRTC, supports H.264, VP8, and H.265 video codecs with codec selection configurable per application through the web panel or REST API, and delivers output across WebRTC (ultra-low latency), HLS and LL-HLS (low latency), and DASH/CMAF (standard latency). This codec-agnostic, multi-protocol architecture is the same foundation that extends to VVC output as FFmpeg’s VVenC integration moves from experimental to production-ready.

Ant Media Server’s adaptive bitrate streaming feature dynamically adjusts video quality based on each viewer’s network speed and device performance, automatically switching between configured resolution and bitrate renditions. When VVC joins the encoding ladder, the ABR engine serves VVC renditions to capable devices and falls back to H.265 or H.264 for others—without requiring separate delivery infrastructure. The adaptive bitrate streaming documentation at docs.antmedia.io covers configuration of custom resolution/bitrate profiles through both the web panel and broadcast-level API.

Understanding how each codec generation affects bandwidth cost and device compatibility is critical for operators planning multi-codec delivery. The video codecs streaming guide examines H.264, H.265, VP9, and AV1 compression efficiency, encoding speed benchmarks, protocol compatibility, and bitrate requirements across 6 resolutions—the codec selection framework that VVC extends with its 50% compression advantage over HEVC.

VVC’s direct predecessor, HEVC, remains the highest-efficiency codec currently supported in Ant Media Server’s transcoding pipeline. The H.265 HEVC codec guide covers Coding Tree Unit architecture, Main 10 profile HDR support, encoding speed comparisons against H.264, and the three-pool HEVC licensing structure that VVC’s own patent landscape closely mirrors.

H.264 serves as the universal fallback codec in every multi-codec delivery architecture, including VVC-ready pipelines. The H.264 AVC codec guide details profile configurations, protocol-specific encoding requirements across RTMP, HLS, and WebRTC, and the 98.23% browser compatibility that makes H.264 the mandatory baseline rendition in adaptive bitrate ladders.

VVC content delivery relies on DASH/CMAF packaging because HLS does not natively support VVC playback. Ant Media Server’s CMAF streaming support provides LL-DASH output with configurable segment and fragment durations—the same packaging format that carries VVC-encoded segments to smart TVs and set-top boxes with hardware decode capability.

VVC encoding requires 8–10x the computational resources of HEVC at equivalent quality, making GPU acceleration essential for any deployment beyond offline VOD processing. Ant Media’s analysis of GPU vs CPU transcoding performance quantifies the latency, throughput, and cost tradeoffs between CUDA-accelerated and software-only encoding—directly relevant to infrastructure sizing for future VVC transcoding workloads.

Scaling transcoding infrastructure for computationally intensive codecs requires container-orchestrated auto-scaling that allocates GPU-equipped workers dynamically. Ant Media Server’s Kubernetes deployment architecture supports horizontal scaling of origin and edge nodes, with auto-scaling triggers based on CPU load and active stream count—the orchestration model that absorbs VVC’s higher encoding complexity without over-provisioning.

Ultra-low-latency ingest via WebRTC with server-side conversion to HLS and DASH output represents the dominant live streaming architecture. Ant Media Server’s WebRTC to HLS/DASH pipeline handles protocol transcoding from WebRTC ingest to segmented HTTP delivery—the same pipeline that will package VVC-encoded output as DASH/CMAF segments for hardware-capable playback endpoints.

Content protection for premium VVC streams applies at the DASH/CMAF packaging stage, where Widevine and PlayReady encryption work identically regardless of the underlying video codec. Ant Media Server’s DRM support for secure streaming covers the encryption workflow for DASH-delivered content—infrastructure that extends to VVC-encoded streams without protocol-level changes.

Cloud deployment with automated cluster provisioning enables cost-efficient scaling for multi-codec transcoding workloads. The AWS CloudFormation scaling guide provides templates for auto-scaling origin-edge clusters on AWS, supporting concurrent H.264 and H.265 transcoding with load-balanced stream distribution across availability zones.

Monitoring transcoding pipeline health becomes critical when operating multi-codec encoding ladders. Ant Media Server’s Grafana monitoring integration provides real-time dashboards tracking per-stream encoding performance, system CPU load, JVM heap memory, and active stream counts—the observability layer that identifies transcoding bottlenecks before they impact viewer experience.

Operators building multi-codec delivery infrastructure need to validate that adaptive bitrate transcoding, DASH/CMAF packaging, WebRTC ingest, and HLS output function correctly before adding codec complexity. Ant Media Server’s self-hosted evaluation provides 14 days of Enterprise Edition access to test H.264, H.265, and VP8 transcoding pipelines, Kubernetes auto-scaling, and multi-protocol output in a production-representative environment—establishing the infrastructure foundation that extends to VVC as encoder support reaches production readiness.

Frequently Asked Questions
What is the H.266 VVC Codec?
H.266 VVC (Versatile Video Coding) is a video compression standard finalized in July 2020 by JVET. VVC achieves 50% bitrate reduction over HEVC at equivalent visual quality through multi-type tree partitioning, affine motion compensation, and adaptive loop filtering. VVC carries the formal designations ITU-T H.266 and ISO/IEC 23090-3.

How Much Bandwidth Does VVC Save Over HEVC?
VVC reduces bitrate by 40–50% compared to HEVC at equivalent perceptual quality. A 4K stream at 12 Mbps in HEVC drops to 6–7 Mbps with VVC. Fraunhofer HHI’s VVenC encoder demonstrated a 39% efficiency gain over x265 in Streaming Media Magazine benchmarks.

Is VVC Royalty-Free Like AV1?
VVC requires royalty payments through Access Advance and Via-LA patent pools, with 17+ essential patent holders remaining outside both pools as of March 2026. AV1 operates royalty-free through the Alliance for Open Media—a distinction that directly determines browser support and web deployment viability.

Which Browsers Support H.266 VVC?
No major browser supports native VVC playback as of March 2026. Chrome, Firefox, Edge, and Safari lack VVC decode. AOMedia member companies that develop these browsers have no commercial incentive to add VVC support, mirroring the limited browser adoption of HEVC.

Does Ant Media Server Support VVC?
Ant Media Server currently supports H.264, VP8, and H.265 (HEVC) codecs for WebRTC, HLS, LL-HLS, and DASH/CMAF delivery. VVC is not yet a supported codec. Ant Media Server’s multi-codec transcoding architecture and DASH/CMAF packaging engine provide the infrastructure foundation that extends to VVC output as FFmpeg’s VVenC integration matures.

When Will VVC Replace HEVC?
VVC coexists with HEVC, AV1, and H.264 rather than replacing any single codec. Broadcast and CTV adopt VVC first through hardware decode mandates. Web streaming continues using H.264 and H.265 for compatibility. Multi-codec adaptive delivery—serving each viewer the best codec their device supports—defines the 2026–2028 deployment model.

Conclusion
H.266 VVC delivers 50% bitrate reduction over HEVC through 6 architectural innovations including MTT partitioning, affine motion compensation, and subpicture streaming. Intel Lunar Lake, MediaTek Pentonic, and DVB-mandated devices establish VVC’s initial deployment in broadcast and connected TV. Patent pool fragmentation with 17+ unlicensed essential patent holders and zero browser support constrain VVC adoption in web-based streaming, where H.265 and H.264 remain the production codecs.

Ant Media Server’s multi-codec architecture—supporting H.264, VP8, and H.265 with adaptive bitrate transcoding across WebRTC, HLS, LL-HLS, and DASH/CMAF—provides the infrastructure foundation for incremental VVC adoption. The same DASH/CMAF packaging pipeline, Kubernetes auto-scaling, and DRM integration that serve H.265 content today extend to VVC streams as encoder libraries and hardware decode support reach production maturity through 2026–2028.

Streaming teams preparing their infrastructure for next-generation codec support can start a 14-day Enterprise Edition trial to validate adaptive bitrate transcoding, multi-protocol delivery, cluster auto-scaling, and DASH/CMAF output in a self-hosted environment—building the production-ready foundation that accommodates VVC the moment encoder integration reaches general availability.

Visit: antmedia.io

Harness Powers of DeepAR and Custom Overlay with Ant Media Android SDK

Akeel Almas — Wed, 11 Mar 2026 10:46:08 +0000

Live streaming has evolved beyond simple camera-to-viewer broadcasts. Today’s audiences expect interactive content with visual effects, branding elements, and augmented reality features.

In this blog, we explore two ways to enhance Android live streams using Ant Media Server
:

• DeepAR integration for real-time AR filters and face effects
• Custom Canvas overlays for adding logos, text, or graphics on the video before streaming

Both approaches use the Ant Media Android SDK
and leverage Ant Media Server’s WebRTC streaming
to deliver ultra-low latency streams with real-time visual enhancements.

GitHub Repository:
https://github.com/USAMAWIZARD/AntMedia-DeepAR-And-Overlay

HD vs SD Streaming: The Broadcaster’s Complete Guide to Choosing the Right Video Resolution

Akeel Almas — Wed, 25 Feb 2026 10:46:43 +0000

Test HD, SD & Adaptive Bitrate Streaming with Ant Media Server

Choosing between HD and SD is easier when you can test both in a real environment.

Ant Media supports streaming from 240p up to 4K with adaptive bitrate (ABR) across WebRTC, HLS, and DASH. You can configure custom bitrate ladders, enable GPU-accelerated transcoding, and monitor real-time bandwidth usage directly from the dashboard.

If you want to validate:

• 480p vs 720p vs 1080p quality
• WebRTC ultra-low latency performance
• ABR switching behavior under real bandwidth conditions
• GPU vs CPU transcoding efficiency

Start with a free trial and test your exact HD/SD configuration before going live.

👉 https://antmedia.io/free-trial/

Run Ant Media Server on Azure — Free Credits Available Through Azure Sponsorship

Akeel Almas — Wed, 18 Feb 2026 10:42:02 +0000

Like every year, Ant Media Server is proud to participate in the Microsoft Azure Sponsorship Program in 2026, offering free infrastructure credits to qualified users.

Azure Sponsorship Program will grant qualified users access to complimentary infrastructure for thorough evaluations of Ant Media Server Enterprise Edition on Azure Marketplace. This program offers evaluation subscriptions to Azure for up to 90 days for qualified proofs of concept (PoC).

Azure Sponsorship
As part of the Microsoft Azure Sponsorship program and in coordination with Microsoft, Ant Media is offering up to $1,000 of free Azure credits of infrastructure for assessments, proof of concepts, and deployments for each applicant. This program could also help for the clients who plans to migrate from Azure Media Services to Ant Media Server in Azure Marketplace.

Available to eligible applicants, who require to have PAYG or EA Subscription on Azure, these funds can help you to experience the live streaming and VoD services with Ant Media Server, and also integration capability with your backend to deliver your use case.

Learn more about Ant Media Server Enterprise Edition Cluster in Azure
To learn more about running Ant Media Enterprise Edition Cluster on Azure, please refer to read this guide.

Learn more about the Microsoft Azure Sponsorship Program
Interested in taking advantage of the Azure Sponsorship Program? Send us a note at contact@antmedia.io to be connected with an Ant Media Solution specialist who can help you get started.

Learn more about how to migrate from Azure Media Services to Ant Media Server
To learn more about switching from Azure Media Services to Ant Media Server Enterprise Edition in Azure Marketplace, please refer to read this guide.

Please just note that Azure Sponsorship can work only on pay-as-you-go (PAYG) or Enterprise Agreement (EA) Azure subscriptions. We cannot add free Azure on any other Azure subscription type (e.g., MCA, through CSP) or to accounts that already have free Azure added to them.

IP Camera Streaming – Full Guide For Beginners

Akeel Almas — Wed, 11 Feb 2026 11:01:56 +0000

If you're looking for a production-ready way to stream IP cameras using RTSP to WebRTC, HLS, or CMAF with ultra-low latency, you can use Ant Media Server. It allows you to ingest RTSP from IP cameras and restream to browsers via WebRTC (sub-second latency) or HLS/CMAF for wider playback support. You can explore the full setup guide here:
👉 https://antmedia.io/ip-camera-streaming-guide-how-to-setup-an-ip-camera/

Bitrate vs. Resolution: 4 Key Differences and Their Role in Video Streaming

Akeel Almas — Wed, 04 Feb 2026 08:44:24 +0000

Understanding video bitrate vs resolution is critical for delivering high-quality, low-latency streaming experiences. While resolution defines how much visual detail a video contains, bitrate determines how efficiently that detail is transmitted over the network. Getting this balance wrong often leads to pixelation, buffering, or unnecessary bandwidth costs.

Modern streaming platforms like Ant Media Server help solve this by combining adaptive bitrate streaming with ultra-low latency protocols such as WebRTC and scalable delivery via HLS. This allows broadcasters to dynamically adjust bitrate, resolution, and frame rate based on network conditions—ensuring smooth playback for live sports, webinars, video calls, and real-time applications.

If you’re building a professional streaming workflow and want sub-second latency with full control over bitrate, resolution, and codecs, learn more at https://antmedia.io
.

3 Simple Steps to Build a ReactJS Component for WebRTC Live Streaming

Akeel Almas — Wed, 28 Jan 2026 09:16:04 +0000

ReactJS is one of the most popular JavaScript frameworks used to power extremely dynamic web applications. By building a ReactJS component, we can develop powerful applications that seamlessly integrate Ant Media Server into React, making it more versatile and engaging.

Ant Media Server provides ultra-low latency WebRTC streaming capabilities that work seamlessly with modern JavaScript frameworks. While Ant Media offers an array of Software Development Kits (SDKs), for React applications, the JavaScript SDK is the ideal choice. In this guide, we will take you through a step-by-step process of harnessing the capabilities of the Ant Media JavaScript SDK in conjunction with React.

Our focus will be on publishing a WebRTC stream, covering all the essential setup steps such as importing dependencies, initializing the SDK, handling publishing events, and designing a user-friendly interface for the ReactJS component.

Let’s dive into the tutorial and get started with integrating Ant Media JavaScript SDK into your ReactJS project!

Table of Contents
Prerequisites
Step 1: Create a New ReactJS Project
Step 2: Install Dependencies
Step 3: Create the ReactJS Component
Understanding the code
Step 4: Update the App Component
Step 5: Run the Application
Play Component
Frequently Asked Questions
Conclusion
Prerequisites
ReactJS Component for WebRTC Live Streaming
Before getting started, make sure you have the following prerequisites:

Node.js installed on your machine
Basic knowledge of React and JavaScript
An Ant Media Server instance (Community or Enterprise Edition)
Full Code is Available on Github.

Step 1: Create a New ReactJS Project
Start by creating a new ReactJS project using Create React App. Open your terminal and run the following command:

1
npx create-react-app ant-media-streaming
This command will create a new directory named ant-media-streaming with a basic React project structure.

Step 2: Install Dependencies
Navigate to the project directory and install the required dependencies. Run the following command:

1
2
3
cd ant-media-streaming
npm i @antmedia/webrtc_adaptor
npm i bootstrap react-bootstrap
This command will install the Ant Media JS SDK, Bootstrap, and React Bootstrap packages. The @antmedia/webrtc_adaptor provides the core functionality for WebRTC streaming integration.

Step 3: Create the ReactJS Component
Inside the src directory, create a new file named PublishingComponent.js. This file will contain the code for the publishing component. Open PublishingComponent.js and add the following code:

Full Code is Available on Github.

import React, { useState, useEffect, useRef } from 'react';
import { Button, Container, Row, Col } from 'react-bootstrap';
import 'bootstrap/dist/css/bootstrap.min.css';
import { WebRTCAdaptor } from '@antmedia/webrtc_adaptor';

const PublishingComponent = () => {
const [publishing, setPublishing] = useState(false);
const [websocketConnected, setWebsocketConnected] = useState(false);
const [streamId, setStreamId] = useState('stream123');
const webRTCAdaptor = useRef(null);
var publishedStreamId = useRef(null);

const handlePublish = () => {
setPublishing(true);
webRTCAdaptor.current.publish(streamId);
publishedStreamId.current=streamId

};

const handleStopPublishing = () => {
setPublishing(false);
webRTCAdaptor.current.stop(publishedStreamId.current);
};

const handleStreamIdChange = (event) => {
setStreamId(event.target.value);
};

useEffect(() => {
if(webRTCAdaptor.current === undefined || webRTCAdaptor.current === null){
webRTCAdaptor.current = new WebRTCAdaptor({
websocket_url: 'wss://test.antmedia.io:/WebRTCAppEE/websocket',
mediaConstraints: {
video: true,
audio: true,
},
peerconnection_config: {
iceServers: [{ urls: 'stun:stun1.l.google.com:19302' }],
},
sdp_constraints: {
OfferToReceiveAudio: false,
OfferToReceiveVideo: false,
},
localVideoId: 'localVideo',
dataChannelEnabled: true,
callback: (info, obj) => {
if (info === 'initialized') {
setWebsocketConnected(true);
}
console.log(info, obj);
},
callbackError: function (error, message) {
console.log(error, message);
},
});
}
}, []);

return (

Publish Page

  <Row className="mb-4">
    <Col>
      <video
        id="localVideo"
        controls
        autoPlay
        muted
        style={{
          width: '40vw',
          height: '60vh',
          maxWidth: '100%',
          maxHeight: '100%',
        }}
      ></video>
    </Col>
  </Row>
  <Row className="justify-content-center">
    <Row>
      <div className="mb-3">
        <input
          className="form-control form-control-lg"
          type="text"
          defaultValue={streamId}
          onChange={handleStreamIdChange}
        />
        <label className="form-label" htmlFor="streamId">
          Enter Stream Id
        </label>
      </div>
    </Row>
    <Col>
      {!publishing ? (
        <Button variant="primary" disabled={!websocketConnected} onClick={handlePublish}>
          Start Publishing
        </Button>
      ) : (
        <Button variant="danger" onClick={handleStopPublishing}>
          Stop Publishing
        </Button>
      )}
    </Col>
  </Row>
</Container>

);
};

export default PublishingComponent;
view rawsrc/PublishingComponent.js delivered with ❤ by emgithub
Understanding the code
Full Code is Available on Github.

Part 1: Importing Dependencies
import React, { useState, useEffect, useRef } from 'react';
import { Button, Container, Row, Col } from 'react-bootstrap';
import 'bootstrap/dist/css/bootstrap.min.css';
import { WebRTCAdaptor } from '@antmedia/webrtc_adaptor';
At the top of this ReactJS component, we import the necessary dependencies for our component. These include React, the useState, useEffect, and useRef hooks, Bootstrap components (Button, Container, Row, and Col), the Bootstrap CSS, and the WebRTCAdaptor from the Ant Media JS SDK.

We imported WebRTCAdaptor from the JS SDK which will act as an interface for us to publish and play streams from Ant Media Server

Part 2: Defining the Publishing Component
const PublishingComponent = () => {
const [publishing, setPublishing] = useState(false);
const [websocketConnected, setWebsocketConnected] = useState(false);
const [streamId, setStreamId] = useState('stream123');

const webRTCAdaptor = useRef(null);
var publishedStreamId = useRef(null);

// ... Rest of the component code ...
}
Here we define the PublishingComponent functional component. Inside this ReactJS component, we use the useState hook to create state variables: publishing, websocketConnected, and streamId. These variables will manage the publishing state, WebSocket connection status, and the entered stream ID, respectively.

We also create a webRTCAdaptor ref using the useRef hook. This ref will hold an instance of the WebRTCAdaptor class from the Ant Media JS SDK.

Part 3: Handling Publishing Events
const handlePublish = () => {
publishedStreamId.current=streamId
setPublishing(true);
webRTCAdaptor.current.stop(streamId);
};

const handleStopPublishing = () => {
setPublishing(false);
webRTCAdaptor.current.stop(publishedStreamId.current);
};

const handleStreamIdChange = (event) => {
setStreamId(event.target.value);
};
Next we define the event handler functions for publishing, stopping publishing, and stream ID change events. The handlePublish function sets the publishing state to true and calls the publish method of the webRTCAdaptor ref with the streamId.

The handleStopPublishing function sets the publishing state to false and calls the stop method of the webRTCAdaptor ref with the publishedStreamId.

The handleStreamIdChange function is triggered when the value of the stream ID input field changes. It updates the streamId state with the new value.

Part 4: Initializing WebRTC Adaptor
Note : Please Change The Ant Media IP in the WebRTCAdaptor Initialization

useEffect(() => {
webRTCAdaptor.current = new WebRTCAdaptor({
websocket_url: 'wss://AMS_IP:/WebRTCAppEE/websocket',
mediaConstraints: {
video: true,
audio: true,
},
peerconnection_config: {
iceServers: [{ urls: 'stun:stun1.l.google.com:19302' }],
},
sdp_constraints: {
OfferToReceiveAudio: false,
OfferToReceiveVideo: false,
},
localVideoId: 'localVideo',
callback: (info, obj) => {
if (info === 'initialized') {
setWebsocketConnected(true);
}
console.log(info, obj);
},
callbackError: function (error, message) {
console.log(error, message);
},
});
}, []);
To initialize the webRTCAdaptor, we’ll use the useEffect hook. The WebRTCAdaptor class handles all WebRTC connection management, including peer connections, media streams, and signaling through WebSocket connections.

The WebRTCAdaptor configuration requires several key parameters including websocket_url, mediaConstraints, and callback functions. For production deployments, you should implement proper stream security and token-based authentication.

Step 4: Update the App Component
Open the src/App.js file and replace its content with the following code:

In the above code, we import the PublishingComponent and render it inside the App component.

import PublishingComponent from './PublishingComponent';
import PlayingComponent from './PlayingComponent';

const App = () => {
return (

);
};

export default App;
view rawsrc/App.js delivered with ❤ by emgithub
Step 5: Run the Application
Save all the changes, and in your terminal, run the following command inside the project directory:

npm start
This command will start the development server, and you can view the application in your browser at http://localhost:3000. You should see the “Live Streaming” heading, a video element for displaying the local video stream, an input field for entering the stream ID, and a “Start Publishing” button.

Play Component
The ReactJS component built for playing the live stream is available here. The Play and Publish components are designed separately, but for the sake of simplicity they can be merged together if preferred. For advanced playback features, explore our complete playback documentation.

To use the player page, create a new component file called PlayingComponent.js and add the following code, which is available here.
Update the root ReactJS component to import the new play component as in the example below.
Run the npm start command in the directory.
import PlayingComponent from './PlayingComponent';

const App = () => {
return (

);
};
react
Player Page
Frequently Asked Questions
Can I use Ant Media JavaScript SDK with React 18?
Yes, the Ant Media JavaScript SDK works with React 18 and all React versions that support ES6+ syntax. The @antmedia/webrtc_adaptor package integrates seamlessly with modern React applications using hooks like useState and useRef.

What is the minimum latency achievable with WebRTC streaming in React?
WebRTC streaming through Ant Media Server achieves sub-second latency, typically between 0.5 to 1 second. This ultra-low latency is maintained regardless of whether you implement the streaming component in React, Vue, or vanilla JavaScript.

Do I need separate components for publishing and playing streams?
No, you can combine publishing and playing functionality in a single React component. However, separating them into distinct components improves code maintainability and allows independent reuse across your application.

How many concurrent streams can a React component handle?
A single React component can handle multiple concurrent streams limited only by browser capabilities and network bandwidth. Ant Media Server’s clustering feature supports scaling to thousands of concurrent viewers per stream.

Can I deploy React WebRTC components in production without modifications?
Yes, but you must replace the development WebSocket URL with your production Ant Media Server URL and implement proper error handling, connection recovery, and user permission management for camera/microphone access.

What browsers support WebRTC with React components?
All modern browsers support WebRTC: Chrome 74+, Firefox 66+, Safari 14+, Edge 79+, and Opera 62+. Mobile browsers including Chrome Mobile and Safari iOS also provide full WebRTC support for React applications.

Conclusion
You’ve now learned how to integrate the Ant Media JavaScript SDK into a ReactJS application to publish and play WebRTC streams with ease. By building reusable React components and leveraging WebRTC’s real-time capabilities, you can create fast, interactive, and highly engaging web experiences.

From setting up the SDK to handling publishing events and managing the UI, this guide gives you the foundation you need to start building real-time video features into your own React projects. Whether you’re working on live events, video conferencing tools, online classrooms, or interactive platforms, Ant Media Server provides the performance and scalability required for production use.

For more advanced implementations, explore our guides on building video conferencing apps, implementing adaptive bitrate streaming, and scaling your infrastructure to handle thousands of concurrent users.

Ready to take your streaming application to the next level? Check out our React Native SDK for building cross-platform mobile applications, or explore live WebRTC samples to see different use cases in action.

Now it’s your turn to experiment, customize, and innovate. Start your free trial with Ant Media Server, explore the SDK further, and bring immersive real-time streaming to your React applications.