DEV Community: Ant Media

How to run MoQ in AWS for sub-second live streaming at scale

Amar Thodupunoori — Fri, 30 Oct 2026 08:12:36 +0000

For years you had to pick one. Real-time latency, or an audience of any size. Media over QUIC gives you both, and you can have it running on an AWS instance this afternoon — publisher, relay and player included.

Why MoQ exists

Until now you picked one of two compromises. WebRTC gave you sub-second latency but no CDN — every viewer is a peer connection, and scaling means an SFU and a lot of servers. LL-HLS gave you CDN scale but four seconds or more of delay, which kills anything interactive.

MoQ removes the choice. It runs on QUIC, so a delayed frame does not block the ones behind it, and it uses WebTransport so it works straight from the browser with no plugin. The result is sub-second latency with a pub/sub delivery model a CDN can actually cache. Cloudflare already runs MoQ at their edge in alpha, so the CDN half is not theoretical.

MoQ compared with WebRTC and LL-HLS across latency, architecture and browser support.


Dimension   MoQ WebRTC  LL-HLS
Latency Sub-second, configurable    0.2–0.5s  4+ seconds
Architecture    Pub/sub + CDN relay SFU CDN / origin
CDN cacheable   Yes No  Yes
Transport   UDP / QUIC / WebTransport   UDP / DTLS-SRTP HTTP
Browser support Chrome, Edge, Safari 26.4+  All major browsers  All major browsers

Source: WebRTC vs MoQ — two protocols, one platform

Running it on AWS

By the end of this you will be publishing from a browser and watching it back less than a second later. There is nothing to compile, and the server issues its own domain and certificate — you do not need to own either. Playback works in Chrome, Edge and Brave, or Safari 26.4 and above.

1. Launch the instance
Subscribe on AWS Marketplace and launch. A c5.xlarge is plenty to start. The AMI arrives with Ant Media Server 3.0.3 already running and every port it needs already open.

Launch the AMI

2. Add port 4443 to the security group
One rule to add, on both TCP and UDP. That is where the MoQ relay listens. Everything else the server needs is already open on the AMI.

Add the UDP rule as well as TCP. With only TCP the pages load normally and the browser then silently never reaches the relay — it is the most common first-run failure.

3. Turn on SSL from the web panel
MoQ uses WebTransport, and browsers only allow that over HTTPS. You do not need to own a domain — the server will give you a free one.

Open the web panel at http://your-server-ip:5080 — that is HTTP on port 5080, which is how the server starts before SSL exists. Go to Settings → SSL, set Type to Subdomain of antmedia.cloud and click Activate.

A subdomain is allocated to you, a Let’s Encrypt certificate is issued and installed, and the server restarts itself. From then on it answers on https://your-subdomain.antmedia.cloud:5443.

4. Install the MoQ plugin
The plugin is a single release archive. You can download MoQPlugin-release.zip to your own machine and upload it, but the curl command below is easier — it pulls the file straight onto the server, so there is nothing to transfer.

SSH in as ubuntu and run these in order:

# fetch the plugin release onto the server
curl -L "https://drive.usercontent.google.com/download?id=1X9ymWsDjfdNdcXH2h0y2Ak2IWpmnkijk&export=download&confirm=t" -o MoQPlugin-release.zip

# unpack it and step into the folder
unzip MoQPlugin-release.zip
cd MoQ-Plugin

# make the installer executable, then run it
chmod +x install-moq-plugin.sh
sudo ./install-moq-plugin.sh

# put the browser publisher and player into your application
sudo mkdir -p /usr/local/antmedia/webapps/live/moq
sudo cp -r moq-ams-player-build/* /usr/local/antmedia/webapps/live/moq

# restart so the server loads the plugin
sudo service antmedia restart

Publish, and watch it back

Two pages are now live on your server. Replace your-subdomain with the address the server allocated you in step 3 — everything after the domain stays exactly as written.

1 · Open the publisher
Enter a stream ID, choose Camera as the source, and hit Start Publishing.
https://your-subdomain.antmedia.cloud:5443/live/moq/play.html

Status flips to publishing, and the relay URL on port 4443 appears at the top alongside the broadcast path.

2 · Open the player in a second window
Enter the same stream ID and pick the source track. The debug panel underneath reports what you are actually getting — frame rate, buffer, stalls and glass-to-glass latency.
https://your-subdomain.antmedia.cloud:5443/live/moq/play.html

source is the original quality as published. If you switch on adaptive bitrate streaming, each rendition the server produces appears here as its own MoQ track — 720p, 480p and so on.

What is running now

Browser publishing and playback at sub-second latency
An embedded moq-lite relay listening on port 4443
Every adaptive rendition exposed as its own MoQ track
Any moq-lite client able to publish straight to the relay

What you can add to it

RTMP, RTSP or SRT in the front, MoQ out the back
The same stream over WebRTC, HLS and DASH simultaneously
Recording, transcoding and control from the REST API
Cloudflare’s MoQ edge in place of the embedded relay

Before you build production on it. MoQ is still being standardised. This plugin implements moq-lite, a deployable subset that already interoperates with full moq-transport CDNs including Cloudflare’s. It is functional and actively maintained — for a serious integration, start in staging and talk to us.

Why run it on AWS specifically

MoQ is a transport. You still need somewhere to ingest, transcode and record — and something that speaks RTMP and RTSP for the sources that will never speak QUIC.

Running it on an AWS instance means the MoQ relay, the media server and the rest of your pipeline sit in one place, on infrastructure you already have committed spend on, and it is licensed per instance-hour rather than per stream or per viewer.

Single instance, single hourly rate, no per-stream or per-viewer fees
Auto-managed deployment for one server, CloudFormation for a multi-node cluster
Draws down against committed AWS spend
Everything stays inside your own account and VPC

Measured on one c5.xlarge

Ant Media Server throughput measured on a single AWS c5.xlarge instance.

Workload Capacity
RTSP camera streams, video only,360p 550
WebRTC publishers, 1080p 35
WebRTC viewers, 1080p 105
RTMP ingest, 1080p 35
SRT ingest, 1080p 42

Sustained at 65–75% CPU. Each figure measured on its own — publish and playback were not run concurrently.

Try it on AWS

Launch, add one port, activate SSL, paste one command. Publisher and player included. Would rather not do the setup? Tell us what you are building and we will deploy the first one for you, free.

Start Free on AWS
7-day free trial · billed per instance-hour · cancel any time

Stream IP Cameras on AWS: RTSP to WebRTC in 4 Steps

Malti Thakur — Thu, 22 Oct 2026 04:28:54 +0000

Your cameras speak RTSP. Your browser doesn't.

That is why so much camera video ends up stuck inside an NVR or a desktop client. What you need is a server in the middle that ingests the RTSP feed and hands the browser WebRTC. This guide walks through setting that up on AWS with Ant Media Server. It takes about ten minutes and ends with a camera playing in a browser tab at roughly half a second of delay.

Step 1: Launch the server

Subscribe to Ant Media Server on AWS Marketplace and launch a c5.xlarge instance. The image boots with the server already running.

Two things to get right at launch:

Keep the recommended security group, or open TCP 5080 and 5443 (panel and HTTPS) and UDP 50000-60000 (WebRTC media).
Attach an Elastic IP so the address doesn't change when the instance restarts.

Step 2: Open the panel

Go to http://your-server-ip:5080 and log in:

Username: JamesBond
Password: your AWS instance ID

Change the password straight away. Port 5080 is plain HTTP, so enable SSL before connecting real cameras, otherwise your login travels unencrypted.

Step 3: Add your camera

Open an application (live exists by default), click New Live Stream, choose Stream Source, name it, and paste the camera's RTSP URL:

rtsp://{username}:{password}@{camera-ip}:554/{stream-path}

The catch: your server is in AWS and your camera is probably on a private network. A 192.168.x.x address is not reachable from EC2. Give the server a route to the camera by using either:

a site-to-site VPN into your VPC (the cleaner option), or
a port-forward on the site router that only accepts connections from the instance's Elastic IP.

Don't expose port 554 to the whole internet.

Click Create Stream. If the URL and credentials are right, the status changes to broadcasting.

Step 4: Watch it live

Open the stream and press play. No plugin, no download, no transcoding job to configure.

It works without video transcoding because the camera's H.264 video passes straight through. If a camera is set to H.265, switch it to H.264 in the camera settings. Browser support for H.265 over WebRTC is still inconsistent, and the server would otherwise have to transcode it.

Why WebRTC instead of HLS?

Protocol	Typical latency	Good for
HLS	8–20 seconds	Reviewing footage, large passive audiences
LL-HLS	3–5 seconds	Near-live viewing where some buffering is fine
WebRTC	Under 0.5 seconds	Security, access control, PTZ, anything someone acts on

All three come off the same ingested stream, so you can send WebRTC to a control room and HLS to everyone's phones without touching the cameras again.

Controlling PTZ cameras

Driving a pan-tilt-zoom camera through a ten-second feed is miserable: you nudge, nothing happens, you nudge again, then both moves arrive at once and you overshoot. With WebRTC you hold the control, see the camera move, and let go where you meant to stop.

For an ONVIF camera, choose IP Camera instead of Stream Source under New Live Stream, then enter the camera's ONVIF URL, username and password. The panel exposes PTZ controls, and the same actions are available through the REST API, so you can put pan, tilt and zoom buttons in your own app.

ONVIF auto-discovery only works when the server is on the same local network as the cameras, so on AWS add cameras by URL.

Capacity: one setting, twelve times the cameras

Most cameras send AAC audio by default. WebRTC doesn't carry AAC, so the server has to transcode every camera's audio to Opus, and that transcode is what eats the CPU, not the video. Nobody is listening to a camera bolted to a corridor ceiling anyway.

Disable audio in each camera's encoder settings and the same c5.xlarge goes from 50 streams to 600 at 360p, with CPU in the low sixties.

On cost, the instance is $0.17/hour on demand (us-east-1) and the Ant Media Server license is $0.63/hour on top. That is about $584 a month with no per-stream or per-viewer license fee, which works out to roughly $1 per camera per month at 600 cameras. The line that does grow is AWS data transfer out, which scales with viewers rather than cameras.

Wrapping up

The flow is: launch the instance, log in, add the RTSP source, press play. The three things that trip people up are network reachability to the camera, H.265 encoding, and camera audio left on.

This is a condensed version. I originally published the full guide, with screenshots and the ONVIF walkthrough, on the Ant Media blog: Stream IP Cameras on AWS: RTSP to WebRTC in 4 Easy Steps

WebRTC Video Streaming: How a Live Broadcast Reaches 0.5s Latency [2026 Update]

Malti Thakur — Fri, 16 Oct 2026 07:39:39 +0000

WebRTC video streaming delivers live audio and video from a publisher to an audience at approximately 0.5 seconds of glass-to-glass latency. Virtual events, live auctions, telehealth consultations and online gaming all depend on that figure, because a delay above one second breaks the interaction the product is built around.

HTTP-based protocols deliver the same stream at 8–12 seconds. WebRTC closes that gap by carrying media over RTP on UDP instead of fetching segments, and by running natively in every modern browser, so viewers join a stream from a URL without installing a plugin or an application.

What is WebRTC?

WebRTC (Web Real-Time Communication) is an open standard from the W3C and IETF that transmits audio, video and arbitrary data directly between browsers and devices. Every WebRTC media path carries DTLS-SRTP encryption by specification, and every modern browser ships the API without a plugin.

Peer connection setup, ICE candidate negotiation and the signaling exchange that precedes media are covered in the guide to how WebRTC works. The rest of this post covers what changes when WebRTC carries a live stream to an audience rather than a call to one other participant.

Why WebRTC Video Streaming Is Transforming Live Streaming

WebRTC video streaming delivers a live feed in approximately 0.5 seconds, against 8–12 seconds for standard HLS and MPEG-DASH. That twenty-fold difference decides whether a viewer participates in an event or watches a recording of one that already finished.

The gap comes from transport. HLS and DASH cut video into segments, publish a manifest, and require the player to buffer several segments before playback starts. WebRTC pushes RTP packets over UDP with no segment boundary and no manifest fetch, so the only accumulated delay is encode time, network transit and jitter buffer depth.

Key Advantages of WebRTC Video Streaming

Six properties separate WebRTC from every HTTP-based delivery protocol:

Sub-second latency – Approximately 0.5 seconds glass-to-glass from publisher camera to viewer screen.
Browser-native playback – Chrome, Safari, Firefox, Edge and Opera decode WebRTC without a plugin or an application install.
Adaptive quality – Bandwidth estimation and adaptive jitter buffering hold playback continuous as network conditions change.
Mandatory encryption – DTLS-SRTP secures every media packet, and the specification permits no unencrypted transmission.
Horizontal scale – An SFU with edge nodes serves an audience the publisher device cannot reach directly.
Data channels – Chat messages, bid values, scores and control commands travel alongside video on the same connection.

Properties one and five interact, and that interaction defines the architecture of every production deployment: the latency figure holds only while the fan-out layer keeps up with the audience.

How Does WebRTC Live Streaming Work for a One-to-Many Broadcast?

WebRTC live streaming moves one publisher's audio and video to a large audience through a media server that terminates the publisher's peer connection and fans the stream out to viewers. A browser opens a peer connection to that server rather than to each viewer, which holds publisher upload bandwidth flat as the audience grows.

Two workloads share the WebRTC protocol and behave differently. WebRTC conferencing connects a small group where every participant publishes and subscribes. WebRTC broadcast moves a single source to viewers who never publish back. A broadcast to 10,000 viewers cannot run peer-to-peer, because one device cannot hold 10,000 simultaneous peer connections.

A production WebRTC broadcast runs through five stages:

Capture the source from a browser, a hardware encoder, or OBS Studio.
Negotiate the session over WebSocket or WHIP signaling before media moves.
Ingest the stream at the origin node, which terminates the DTLS-SRTP handshake.
Route the stream to edge nodes that pull from origin and serve viewers.
Deliver playback over WebRTC, LL-HLS or MoQ depending on the latency target.

Stages three and four separate a live broadcast from a video call. Ant Media Server accepts non-WebRTC sources on the same origin — RTMP, SRT, RTSP, NDI and Zixi — so a WebRTC audience watches a stream that never started as WebRTC.

The table below maps four audience sizes to the infrastructure each one requires.

Audience Size	Topology	Server Requirement
2 participants	Peer-to-peer with STUN	Signaling and STUN only
3–4 participants	Mesh	Signaling and STUN only
5–100 participants	SFU	Single media server node
One-to-many broadcast	SFU plus edge cluster	Origin node plus edge nodes

The jump from row three to row four is the decisive one. A single node serves up to 200 concurrent viewers at 360p on 4 CPU cores, and capacity past that figure comes from adding edge nodes rather than adding cores to one machine.

What Latency Does WebRTC Video Streaming Actually Deliver?

WebRTC video streaming delivers approximately 0.5 seconds of glass-to-glass latency between a publisher's camera and a viewer's screen. That figure covers capture, encode, ICE-negotiated UDP transport, server-side forwarding, jitter buffering and decode.

Delivery protocol sets the latency the audience experiences, and ingest protocol barely moves it. The table below compares the three delivery tiers Ant Media Server produces from a single ingest.

Delivery Protocol	End-to-End Latency	Best For
WebRTC	~0.5 seconds	Auctions, betting, conversation, remote control
LL-HLS and LL-DASH (CMAF)	3–5 seconds	Large audiences needing near-real-time
HLS	8–10 seconds	Maximum device reach, one-way viewing

The gap between row one and row three is roughly twenty-fold, which is why delivery choice outranks ingest choice in almost every architecture decision.

What Pushes WebRTC Latency Above 0.5 Seconds?

Four conditions raise measured latency above the 0.5-second figure:

TURN relay replaces the direct media path when symmetric NAT blocks it, adding the round trip to the relay server.
Server-side transcoding decodes and re-encodes the stream to produce adaptive bitrate renditions, which costs frames.
Geographic distance between publisher, origin node and viewer adds propagation delay no protocol removes.
Edition mismatch caps playback: Ant Media Server Community Edition ingests WebRTC but plays back over HLS at 8–12 seconds, while Enterprise Edition plays WebRTC back at 0.5 seconds.

The fourth condition catches the most projects. A team benchmarks a free WebRTC server, measures eight seconds, and concludes WebRTC is slow — when the protocol was never in the playback path.

Published figures describe a reference network. The only latency number that reflects a specific deployment comes from measuring publish-to-play delay on that deployment's own network path.

RTMP to WebRTC Migration: Why It's Essential

RTMP survives as an ingest protocol and has no role in delivery. Adobe ended Flash Player support in 2020, and iOS, Android and every modern browser reject RTMP for playback, which leaves it as an encoder-to-server contribution path carrying roughly 5 seconds of latency.

Migration therefore splits into two separate decisions. Replacing RTMP delivery with WebRTC removes 4.5 seconds from the viewer path. Replacing RTMP ingest with WHIP removes the remaining hop, and the full latency comparison across eight protocols sits in the guide to streaming protocol latency.

Projects that keep an RTMP encoder fleet convert server-side instead, publishing RTMP to the origin and delivering WebRTC to viewers. The distinction between the two delivery models is covered in real-time streaming vs live streaming.

Which Software Publishes a WebRTC Video Stream?

Four client types publish a WebRTC video stream: a browser using getUserMedia, OBS Studio over WHIP, FFmpeg through its WHIP muxer, and a native SDK on iOS, Android, Flutter, React Native or Unity. Each terminates against the same server ingest endpoint.

Hardware encoders are the exception. Most broadcast encoders and streaming cameras carry no native WebRTC support, so those workflows publish over SRT or RTMP and let the server convert to WebRTC for delivery.

Publishing Client	Signaling	Install Required	Typical Use
Browser (getUserMedia)	WebSocket or WHIP	No	Webcam broadcast, guest contribution
OBS Studio 30+	WHIP	Yes	Produced multi-source broadcast
FFmpeg (WHIP muxer)	WHIP	Yes	Automated and headless pipelines
Mobile and Unity SDKs	WebSocket	App build	In-app publishing
Hardware encoder	SRT or RTMP, converted server-side	Device	Broadcast contribution

Row two changed the field. WHIP became an IETF standard as RFC 9725 in March 2025, and OBS Studio added native WHIP output in version 30.0, which removed the RTMP hop and its 5-second penalty from the ingest path.

Ant Media Server has accepted WHIP ingest since version 2.10.0, tested against OBS Studio and the Eyevinn WHIP client, on an endpoint of the form:

https://your-domain:5443/{application}/whip/{streamId}

Selecting the server behind that endpoint is a separate decision, and the guide to WebRTC server types compares eight production servers on license, ingest support and built-in HTTP delivery.

Why Does a WebRTC Video Stream Fail to Connect or Play?

A WebRTC video stream fails for four reasons: blocked media permissions, failed NAT traversal, a codec the receiving browser cannot decode, or insufficient upload bandwidth. Each produces a distinct symptom, which makes diagnosis fast once the symptom is matched to its cause.

Symptom	Cause	Resolution
Camera or microphone never activates	A `Permissions-Policy` response header sets `camera=()` or `microphone=()`, which blocks getUserMedia before the browser prompts	Allow the origin in the header, or drop the directive on pages that publish
Screen share button does nothing	The `display-capture` directive is unset or restricted, and an iframe needs it delegated explicitly	Add `display-capture=(self)` and set `allow="display-capture"` on the iframe
Connection negotiates then drops to nothing	Symmetric NAT or a corporate firewall blocks the direct path, and no TURN server relays the media	Deploy a TURN server and supply its credentials in the ICE configuration
Audio plays, video stays black	The publisher encoded a codec the receiving browser lacks — H.265 sits outside standard browser WebRTC	Publish H.264 or VP8, or transcode server-side

Row three accounts for the majority of production incidents, because it passes every test on an office network and fails on the first corporate viewer. Deployments serving enterprise audiences configure TURN before launch rather than after the first support ticket.

Setting iceTransportPolicy: "relay" in the peer connection configuration forces every candidate through TURN, which confirms whether a relay path works before anything else gets diagnosed. Configuration for restrictive network paths is covered in the guide to NAT traversal setup.

Reproducing symmetric NAT behaviour, adaptive jitter buffering under packet loss and TURN relay fallback demands a running origin node rather than a local test page, because a browser-to-browser loopback never exercises the server-side ICE candidate selection path where these failures occur. A 14-day trial licence runs the Enterprise build with WebRTC playback, WHIP ingest and clustering enabled, places no cap on broadcasters or viewers, and requires no credit card — enough to measure glass-to-glass latency and TURN relay success rate on the same network the production audience uses.

WebRTC Video Streaming with Ant Media Server

Ant Media Server ingests WebRTC, WHIP, RTMP, SRT, RTSP, NDI and Zixi on a single origin, then delivers the same stream over WebRTC, HLS streaming, LL-HLS, LL-DASH, CMAF streaming and MoQ. One ingest feeds every delivery tier without a second encoding pipeline.

Why Choose Ant Media for WebRTC?

Five capabilities decide the fit for a WebRTC broadcast workload:

0.5-second playback – Enterprise Edition delivers WebRTC glass-to-glass at approximately 0.5 seconds.
Origin-edge clustering – Virtual machines, Docker containers and Kubernetes carry the same cluster, and the cluster license adds no premium over the standard Enterprise license.
Multi-protocol delivery – WebRTC, LL-HLS, LL-DASH, CMAF and MoQ from one ingest.
Open-source Community Edition – Apache-licensed builds cover WebRTC ingest with HLS playback at 8–12 seconds.
Deployment breadth – AWS, Google Cloud, Microsoft Azure, DigitalOcean, Oracle Cloud, on-premises hardware and offline environments.

Capability two carries the most weight for a live broadcast, because publisher-side bandwidth stays flat while edge nodes absorb the audience. Node counts, load balancer placement and auto-scaling triggers are covered in the guide to WebRTC clustering architecture.

Frequently Asked Questions

What makes WebRTC different from other streaming protocols?

WebRTC carries media over RTP on UDP and delivers approximately 0.5 seconds of glass-to-glass latency. HLS and MPEG-DASH fetch HTTP segments and deliver the same stream at 8–12 seconds. That twenty-fold gap is why auctions, betting, telehealth and remote control run on WebRTC.

Does WebRTC require plugins or special software?

No. WebRTC runs natively in Chrome, Safari, Firefox, Edge and Opera, so a viewer joins a stream from a URL. Publishing a produced multi-source layout uses OBS Studio 30 or later over WHIP, and headless pipelines use FFmpeg.

Can WebRTC handle large-scale live streaming events?

Yes. A media server terminates the publisher's peer connection and fans the stream out through edge nodes, which holds publisher upload bandwidth flat regardless of audience size. A 4-core node serves up to 200 concurrent viewers at 360p, and capacity beyond that comes from adding edge nodes.

What software do I need to publish a WebRTC video stream?

A browser, OBS Studio 30 or later, FFmpeg, or a native mobile SDK publishes WebRTC directly. OBS and FFmpeg use WHIP, the IETF ingest standard published as RFC 9725 in March 2025. Hardware encoders publish over SRT or RTMP, and the server converts to WebRTC for delivery.

Why is my WebRTC stream slower than 500 milliseconds?

TURN relay, server-side transcoding, geographic distance and edition mismatch each add delay. Edition mismatch is the most common cause: Community Edition ingests WebRTC but plays back over HLS at 8–12 seconds, so the measurement never tested WebRTC playback at all.

Does WebRTC video streaming work behind a corporate firewall?

Yes, with a TURN server configured. Symmetric NAT and strict firewall rules block the direct media path, and TURN relays the session instead. Deployments without TURN negotiate a connection that then carries no media, which is the most frequent production failure on enterprise networks.

What are WebRTC Data Channels used for?

Data channels carry non-media payloads on the same peer connection as video: chat messages, bid values, gaming inputs, scores and control commands. The channel inherits the connection's DTLS encryption and its sub-second timing, which keeps interaction synchronised with the picture.

Why migrate from RTMP to WebRTC?

RTMP delivers at roughly 5 seconds and no modern browser plays it back. WebRTC delivers at approximately 0.5 seconds with DTLS-SRTP encryption mandatory and native browser playback. RTMP retains one role in 2026: encoder-to-server ingest, which WHIP now replaces on WebRTC-native pipelines.

Conclusion

WebRTC video streaming delivers approximately 0.5 seconds glass-to-glass, roughly twenty times faster than standard HLS at 8–12 seconds. Reaching that figure for a one-to-many broadcast takes a media server, an origin node and an edge cluster, because a publisher device cannot open a peer connection to every viewer.

Ant Media Server ingests WebRTC, WHIP, RTMP, SRT, RTSP, NDI and Zixi on one origin, then delivers WebRTC at 0.5 seconds, LL-HLS and LL-DASH at 3–5 seconds, and HLS at 8–10 seconds from the same stream. Teams weighing real-time delivery against Low-Latency HLS run both outputs from a single ingest and compare them side by side.

Measuring adaptive jitter buffering under packet loss, TURN relay fallback behind symmetric NAT and edge node fan-out at audience scale requires a running origin rather than a published benchmark, because glass-to-glass latency depends on the network path between publisher, origin and viewer. A sub-second playback trial runs for 14 days on the Enterprise build with WebRTC playback, WHIP ingest, adaptive bitrate transcoding and clustering enabled, places no cap on broadcasters or viewers, and requires no credit card.

Originally published on the Ant Media blog.

WebRTC Servers Explained: Signaling, TURN, SFUs and How to Set One Up

Malti Thakur — Tue, 13 Oct 2026 18:44:41 +0000

WebRTC is peer-to-peer by design, which leads many developers to assume they don't need any server infrastructure. That works for a simple call between two browsers. It breaks down once you deal with restrictive networks, group calls, or broadcasting to an audience.

What a WebRTC server does

"WebRTC server" really covers four separate jobs:

Signaling: exchanging SDP offers, answers and ICE candidates so endpoints can agree on codecs, addresses and keys
NAT traversal: STUN reports a device's public address; TURN relays media when a direct path fails, for example behind symmetric NAT or strict corporate firewalls
Media routing: forwarding or mixing streams once there are more than two participants
Fan-out: serving one publisher's stream to an audience the publisher can't connect to directly

A two-person call needs the first two. A broadcast to 10,000 viewers needs all four.

Do you need one?

Every WebRTC session needs signaling and STUN, even a two-person call. What else you need depends on the use case:

2 participants: signaling + STUN, plus TURN for sessions that fail direct connectivity
3–4 participants: same stack, and a mesh topology still holds up
5+ participants: add an SFU
One-to-many broadcast: add an SFU and edge nodes

Mesh, MCU or SFU

Mesh: every participant connects to every other. It works up to roughly four users and needs no media server.
MCU: the server decodes and mixes all streams into one composite. Client bandwidth stays flat, but server CPU cost is high.
SFU: the server forwards streams without re-encoding. It scales past 100 participants at moderate server cost.

The network topology guide covers the bandwidth maths in more depth.

Ingest: getting a stream to the server

A publisher can be a browser (getUserMedia), a hardware encoder, or OBS Studio. WHIP standardises WebRTC ingest into a single HTTP POST carrying the SDP offer, instead of custom signaling. The endpoint shape looks like this:

https://your-domain:5443/{application}/whip/{streamId}

Some servers also accept non-WebRTC sources such as SRT, RTSP and NDI. That lets a WebRTC audience watch a stream that never started as WebRTC.

Delivery latency matters more than ingest

Once a stream is on the server, the delivery protocol sets what viewers experience:

Protocol	Typical latency	Good for
WebRTC	~0.5 s	Auctions, betting, conversation, remote control
LL-HLS / LL-DASH	3–5 s	Large audiences needing near-real-time
HLS	8–10 s	Maximum device reach, one-way viewing

That's roughly a twenty-fold gap between the first and last rows. For many products it's the main architectural decision. For more on bridging real-time ingest to HTTP delivery, see WebRTC to HLS and DASH.

Comparing eight open-source servers

Eight projects cover most self-hosted deployments. Each optimises for a different goal:

Server	License	Language	Best fit
Ant Media Server	Apache-2.0 (CE) / commercial (EE)	Java	Broadcast and conferencing
LiveKit	Apache-2.0	Go	Conferencing and AI agents
mediasoup	ISC	C++ / Node.js API	SFU library with fine simulcast control
Janus	GPLv3	C	SIP/PBX bridging, modular gateway
Jitsi Videobridge	Apache-2.0	Kotlin / Java	Ready-made conferencing
Pion	MIT	Go	Building your own SFU from a library
MediaMTX	MIT	Go	Protocol relay (WebRTC, RTMP, SRT, RTSP)
Kurento	Apache-2.0	Java	Media processing pipelines

Two things narrow the shortlist quickly.

1. HTTP delivery. Five of the eight include no built-in HLS/DASH output. If you need real-time and large-audience playback together, you'll end up running a second system.

2. Licensing. Apache-2.0, MIT and ISC all allow closed-source products. GPLv3 (Janus) requires derivative works to carry the same license unless you buy a commercial one. Check this before the media layer is embedded in a shipped product.

Self-hosted vs managed API

The main trade-offs are cost shape and control:

Self-hosted: flat cost as usage grows, and media stays inside your own infrastructure. That matters for regulated areas like telehealth or finance. You take on patching, scaling and monitoring.
Managed API: no infrastructure to run, but fees scale with usage, and media passes through the vendor.

Hardware sizing

Capacity scales close to linearly with cores. Ant Media's published benchmark at 360p:

CPU cores	Broadcasts	Viewers	RAM
4	Up to 50	Up to 200	8 GB
8	Up to 100	Up to 400	16 GB
16	Up to 200	Up to 800	16 GB
32	Up to 400	Up to 2,000	16 GB

Past that, you scale by adding clustered nodes rather than cores. See the docs on clustering and scaling and Kubernetes.

Security basics

WebRTC encrypts media with DTLS-SRTP by default. For production, add HTTPS/WSS on the signaling channel, token-based publish and play authorisation (for example JWT stream tokens), and firewall rules that limit the media port range. See also the notes on WebRTC security.

Setting up a first stream

Provision a Linux host with 4 vCPUs, 8 GB RAM and SSD storage. Open port 5443 plus the UDP range used for media.
Install the server. The Community Edition builds are on GitHub. It ingests WebRTC but plays back over HLS at 8–12 s. WHIP, clustering and sub-second WebRTC playback are Enterprise features in Ant Media Server's case.
Publish a test stream, open the player on a second device and measure the delay. That's the only latency number that reflects your own network.

Full setup details are in the documentation, and questions go to the developer community.

Takeaway

Choose the server whose default architecture matches your workload. Adding broadcast behaviour to a conferencing-focused SFU later usually costs more engineering time than picking the right tool early.

Originally published at antmedia.io.

Flutter Video Conference App for iOS, Android, Web and Desktop.

Malti Thakur — Thu, 08 Oct 2026 06:43:24 +0000

Originally published on the Ant Media blog.

By the end of this guide you'll have a working Flutter video conference app running on your iPhone, with people joining the same call from their browsers. Because it's built with Flutter, the same code also runs on Android, the web, Windows, macOS and Linux, and the sample project and the Ant Media Flutter SDK give you everything you need to shape the app to your own product.

Why Flutter for a Video Conference App?

Flutter lets you write the video conference app once and run it almost everywhere. One Dart codebase builds native apps for iOS and Android, a web app, and desktop apps for Windows, macOS and Linux. The Ant Media Flutter SDK handles the WebRTC connection to Ant Media Server on top of that, so the call screen you set up in this guide is the same one your Android, web and desktop users get, with around 0.5 seconds of latency.

This guide uses an iPhone because iOS has the most setup steps: code signing, Developer Mode and device trust. Once the app runs there, running it on an Android phone is a single flutter run.

What Do You Need Before You Start?

You need four things:

A Mac with the latest Xcode and the Flutter SDK installed
An iPhone and a USB cable
An Apple ID: a free account is enough
A running Ant Media Server Enterprise Edition. Conferencing is an Enterprise Edition feature; with Community Edition, the Flutter SDK supports WebRTC publishing only. If you don't have a server yet, pick one of these:
- 14-day free trial (self-hosted): fill in the trial request form, get the license key by email, then follow the installation guide. No credit card required.
- Buy a license: monthly or annual subscription, or a one-time perpetual license. See Ant Media Server pricing.

Throughout this guide, AMS_HOST is the server address: an IP address (for example 192.168.1.20) or a domain name.

Step 1: Confirm the iPhone Reaches Ant Media Server

Open Safari on the iPhone and load the Ant Media Server web panel:

http://AMS_HOST:5080

Result: the Ant Media Server page loads in Safari.

Every later step depends on this connection, so fix it first when the page does not load. When Ant Media Server runs on the Mac, use the Mac's IP address, never localhost. The command ipconfig getifaddr en0 prints the Mac's IP address.

Step 2: Clone the Flutter SampleProject

Clone the Ant Media Flutter SDK repository and install the SampleProject dependencies. SampleProject bundles all 5 modes (Publish, Play, Peer to Peer, Conference and Data Channel) in one app.

git clone https://github.com/ant-media/WebRTC-Flutter-SDK.git
cd WebRTC-Flutter-SDK/example/SampleProject
flutter pub get
cd ios && pod install && cd ..

Result: the terminal prints Pod installation complete!

Step 3: Sign the App in Xcode

iOS installs only apps signed with an Apple ID. Open the Xcode workspace:

open ios/Runner.xcworkspace

In Xcode, complete these 5 actions in order:

Click the blue Runner icon in the left sidebar.
Select Runner under TARGETS.
Open the Signing & Capabilities tab.
Tick Automatically manage signing and choose your Apple ID under Team.
Change Bundle Identifier to a unique value, such as com.yourname.conferencedemo.

Result: the Signing section shows no red errors.

Step 4: Enable Developer Mode on the iPhone

Developer Mode lets Xcode and Flutter install debug builds on the iPhone. Complete these 3 actions:

Connect the iPhone to the Mac and tap Trust on the phone.
Open Settings → Privacy & Security → Developer Mode on the iPhone, turn Developer Mode on and restart. The option appears only after the phone has connected to Xcode.
Run the device list command on the Mac:

flutter devices

Result: the iPhone appears in the device list. Copy the iPhone's device ID for Step 5.

Step 5: Run the App on the iPhone

Build and launch the SampleProject on the iPhone with the copied device ID:

flutter run -d YOUR_DEVICE_ID

iOS blocks the first launch as an untrusted developer. Open Settings → General → VPN & Device Management on the iPhone, trust your Apple ID, and run the command again.

Result: the app lists 5 modes: Play, Publish, Peer to Peer, Conference and Data Channel.

Step 6: Connect the App to the WebSocket URL

Tap the settings icon (top right) and enter the WebSocket URL of the WebRTCAppEE application, the default Enterprise Edition application:

ws://AMS_HOST:5080/WebRTCAppEE/websocket

Servers with SSL on a domain use wss://AMS_HOST:5443/WebRTCAppEE/websocket instead.

Result: the server indicator turns green.

Step 7: Join the Conference Room from the iPhone

Join room demo from the iPhone with these 4 actions:

Tap Conference.
Enter a Stream ID, for example iphone.
Enter the Room ID demo.
Tap Connect, then allow camera, microphone and local network access.

Result: the iPhone camera appears in the first tile.

Step 8: Add 3 Browser Participants

Open the multitrack conference sample page in three browser tabs to add three more people to room demo. Browsers allow camera access over http:// only on localhost, so choose the URL that matches the server setup.

Option A — browser on the machine running Ant Media Server:

http://localhost:5080/WebRTCAppEE/multitrack-conference.html?roomId=demo

Option B — any computer, server with SSL:

https://AMS_HOST:5443/WebRTCAppEE/multitrack-conference.html?roomId=demo

Option C — any computer, server without SSL (development only): add http://AMS_HOST:5080 to chrome://flags/#unsafely-treat-insecure-origin-as-secure in Chrome, relaunch Chrome, then open http://AMS_HOST:5080/WebRTCAppEE/multitrack-conference.html?roomId=demo.

Click Join Room in each tab and allow the camera.

Result: the iPhone shows the three browser participants alongside its own camera. Open more tabs, or join from other devices with the same Room ID, to add more people.

Step 9: Test Controls and Adaptive Bitrate

Test the 2 conference features on the iPhone:

Camera and microphone: tap the buttons at the bottom of the screen. Each button turns red while its device is off.
Adaptive bitrate: each tile shows that participant's resolution and bitrate. Open Settings → Developer → Network Link Conditioner on the iPhone, choose the 3G profile and turn it on. The resolution and bitrate values drop, then recover when Network Link Conditioner is off.

How Do You Fix the 8 Common Setup Errors?

Each of the 8 setup errors below has a single fix, covering server reachability, room mismatches, permissions, code signing, stream IDs and CocoaPods.

Problem	Fix
The app never connects	Repeat Step 1. On a physical iPhone, `localhost` refers to the phone itself; use the server's IP address or domain.
Browser participants do not appear on the iPhone	Use the same application (`WebRTCAppEE`) and the same room on every device. Open `multitrack-conference.html`, not `conference.html`, because the Flutter SDK joins track-based SFU conferences and the browser page has to match that room type.
Browser tabs cannot access the camera	The page is loaded over `http://` from a host other than `localhost`. Install an SSL certificate and use port 5443; the guide to enabling SSL certificates covers the domain setup. Option C in Step 8 covers development-only testing.
The app cannot reach a server on the local network	The local network permission was denied. Enable the app under Settings → Privacy & Security → Local Network.
Xcode: "cannot be registered to your development team"	The bundle identifier is taken. Change the bundle identifier to a unique value (Step 3).
"This app can only be launched from Flutter tooling"	Debug builds start only through `flutter run`. Start the app from the Mac instead of tapping the icon.
`invalidStreamName` error	Use only English letters and numbers in stream IDs.
`pod install` fails with `XCLocalSwiftPackageReference`	CocoaPods is older than 1.16. Upgrade with `brew upgrade cocoapods` (Homebrew installs) or `sudo gem install cocoapods` (RubyGems installs).

The room mismatch in row 2 is the error most specific to this tutorial: every device connects to Ant Media Server successfully, yet the iPhone and the browser tabs never see each other because the devices joined different room types.

What Can You Build Next?

Your conference app works. From here you can:

Run it on other platforms. Flutter builds the same code for Android, the web, Windows, macOS and Linux, so you don't rewrite the call screen for each one.
Make it interactive. Send chat messages, reactions or other in-call events over WebRTC data channels, without touching audio or video.
Try the other SDK modes. The same sample app includes Publish & Play for one-to-many streaming and P2P for direct calls. The Flutter SDK documentation covers each mode.

Frequently Asked Questions

Does Ant Media Server Community Edition support Flutter video conferencing?

No. Flutter video conferencing requires Ant Media Server Enterprise Edition. With Community Edition, the Flutter SDK supports WebRTC publishing only; WebRTC playback, conference rooms and data channels are Enterprise Edition features.

Which WebSocket URL does the Flutter app use?

The Flutter app uses ws://AMS_HOST:5080/APP_NAME/websocket without SSL and wss://AMS_HOST:5443/APP_NAME/websocket with SSL. This tutorial uses WebRTCAppEE as the application name. Production apps use wss:// on port 5443.

Why does the browser use multitrack-conference.html?

The browser uses multitrack-conference.html because the Flutter SDK joins multitrack conference rooms. The Flutter SDK's Room ID parameter targets WebRTC multitrack conference mode, and a browser participant appears on the iPhone only when the browser page joins the same room type.

How does adaptive quality work in the conference?

Adaptive quality lowers each stream's resolution and bitrate when bandwidth drops and raises both when bandwidth recovers. The tile captions display the current values, and the relationship between bitrate and resolution explains why both numbers move together.

Does the conference work when participants are on different networks?

Yes. Participants on different networks connect through STUN, and participants behind restrictive firewalls require a TURN server. The Flutter SDK's connect() method accepts a custom ICE server list. The guide to NAT traversal setup covers TURN configuration.

Does the same Flutter app run on Android?

Yes. The same SampleProject runs on Android without code changes. Enable developer options and USB debugging on the Android device, connect the device, and run the project with flutter run or from Android Studio.

How do you secure Flutter conference rooms?

Flutter conference rooms are secured with stream tokens passed through the token parameter of connect(). Ant Media Server validates the token before allowing publish or play. JWT stream security adds time-based expiration to each token.

What is the difference between the Flutter SDK and the native iOS SDK?

The Flutter SDK builds one codebase for iOS and Android; the native iOS SDK builds iOS-only apps in Swift. Teams with an existing Swift app start from the native iOS SDK. Both SDKs ship free with an Enterprise Edition license.

Conclusion

You now have a multi-party Flutter video conference app running on your iPhone, with browser participants in the same room, camera and microphone controls, and video quality that adapts to the network. The same Flutter code runs on Android, the web and desktop, so the next step is taking it to the platforms your users are on. To test multi-party WebRTC rooms beyond a single server, a 14-day free trial of Ant Media Server Enterprise Edition gives you clustering, adaptive bitrate and every SDK, with no credit card required.

Source code: Ant Media Flutter SDK on GitHub.

Flutter Video Conference App for iOS, Android, Web and Desktop

Amar Thodupunoori — Wed, 07 Oct 2026 16:53:35 +0000

By the end of this guide you’ll have a working Flutter video conference app running on your iPhone, with people joining the same call from their browsers. Because it’s built with Flutter, the same code also runs on Android, the web, Windows, macOS and Linux, and the sample project and the Ant Media Flutter SDK give you everything you need to shape the app to your own product.

Why Flutter for a Video Conference App?
What Do You Need Before You Start?
Step 1: Confirm the iPhone Reaches Ant Media Server
Step 2: Clone the Flutter SampleProject
Step 3: Sign the App in Xcode
Step 4: Enable Developer Mode on the iPhone
Step 5: Run the App on the iPhone
Step 6: Connect the App to the WebSocket URL
Step 7: Join the Conference Room from the iPhone
Step 8: Add 3 Browser Participants
Step 9: Test Controls and Adaptive Bitrate
How Do You Fix the 8 Common Setup Errors?
What Can You Build Next?
Frequently Asked Questions
Conclusion

Why Flutter for a Video Conference App?

Flutter lets you write the video conference app once and run it almost everywhere. One Dart codebase builds native apps for iOS and Android, a web app, and desktop apps for Windows, macOS and Linux. The Ant Media Flutter SDK handles the WebRTC connection to Ant Media Server on top of that, so the call screen you set up in this guide is the same one your Android, web and desktop users get, with around 0.5 seconds of latency.

This guide uses an iPhone because iOS has the most setup steps: code signing, Developer Mode and device trust. Once the app runs there, running it on an Android phone is a single flutter run.

What Do You Need Before You Start?
You need four things:

A MAC with the latest Xcode and the Flutter SDK installed
An iPhone and a USB cable
An Apple ID: a free account is enough
A running Ant Media Server Enterprise Edition. Conferencing is an Enterprise Edition feature; with Community Edition, the Flutter SDK supports WebRTC publishing only. If you don’t have a server yet, pick one of these:
- 14-day free trial (self-hosted): fill in the trial request form, get the license key by email, then follow the installation guide. No credit card required.
- Buy a license: monthly or annual subscription, or a one-time perpetual license. See Pricing

Throughout this guide, AMS_HOST is the server address: an IP address (for example 192.168.1.20) or a domain name.

Step 1: Confirm the iPhone Reaches Ant Media Server

Open Safari on the iPhone and load the Ant Media Server web panel:

http://AMS_HOST:5080

Result: the Ant Media Server page loads in Safari.

Every later step depends on this connection, so fix it first when the page does not load. When Ant Media Server runs on the Mac, use the Mac’s IP address, never localhost. The command ipconfig getifaddr en0 prints the Mac’s IP address.

Step 2: Clone the Flutter SampleProject

Clone the Ant Media Flutter SDK repository and install the SampleProject dependencies. SampleProject bundles all 5 modes (Publish, Play, Peer to Peer, Conference and Data Channel) in one app.

git clone https://github.com/ant-media/WebRTC-Flutter-SDK.git
cd WebRTC-Flutter-SDK/example/SampleProject
flutter pub get
cd ios && pod install && cd ..

Result: the terminal prints **Pod installation complete!**

Step 3: Sign the App in Xcode

iOS installs only apps signed with an Apple ID. Open the Xcode workspace:

open ios/Runner.xcworkspace

In Xcode, complete these 5 actions in order:

Click the blue Runner icon in the left sidebar.
Select Runner under TARGETS.
Open the Signing & Capabilities tab.
Tick Automatically manage signing and choose your Apple ID under Team.
Change Bundle Identifier to a unique value, such as com.yourname.conferencedemo.

Result: the Signing section shows no red errors.

Step 4: Enable Developer Mode on the iPhone

Developer Mode lets Xcode and Flutter install debug builds on the iPhone. Complete these 3 actions:

Connect the iPhone to the Mac and tap Trust on the phone.
Open Settings → Privacy & Security → Developer Mode on the iPhone, turn Developer Mode on and restart. The option appears only after the phone has connected to Xcode.
Run the device list command on the Mac:

flutter devices

Result: the iPhone appears in the device list. Copy the iPhone’s device ID for Step 5.

Step 5: Run the App on the iPhone

Build and launch the SampleProject on the iPhone with the copied device ID:

flutter run -d YOUR_DEVICE_ID

iOS blocks the first launch as an untrusted developer. Open Settings → General → VPN & Device Management on the iPhone, trust your Apple ID, and run the command again.

Result: the app lists 5 modes: Play, Publish, Peer to Peer, Conference and Data Channel.

Step 6: Connect the App to the WebSocket URL

Tap the settings icon (top right) and enter the WebSocket URL of the WebRTCAppEE application, the default Enterprise Edition application:

ws://AMS_HOST:5080/WebRTCAppEE/websocket

Servers with SSL on a domain use wss://AMS_HOST:5443/WebRTCAppEE/websocket instead.

Result: the server indicator turns green.

Step 7: Join the Conference Room from the iPhone

Join room demo from the iPhone with these 4 actions:

Tap Conference.
Enter a Stream ID, for example iphone.
Enter the Room ID demo.
Tap Connect, then allow camera, microphone and local network access.

Result: the iPhone camera appears in the first tile.

Step 8: Add 3 Browser Participants

Open the multitrack conference sample page in three browser tabs to add three more people to room demo. Browsers allow camera access over http:// only on localhost, so choose the URL that matches the server setup.

Option A — browser on the machine running Ant Media Server:

http://localhost:5080/WebRTCAppEE/multitrack-conference.html?roomId=demo

Option B — any computer, server with SSL:

https://AMS_HOST:5443/WebRTCAppEE/multitrack-conference.html?roomId=demo

Option C — any computer, server without SSL (development only): add http://AMS_HOST:5080 to chrome://flags/#unsafely-treat-insecure-origin-as-secure in Chrome, relaunch Chrome, then open http://AMS_HOST:5080/WebRTCAppEE/multitrack-conference.html?roomId=demo.

Click Join Room in each tab and allow the camera.

Result: the iPhone shows the three browser participants alongside its own camera. Open more tabs, or join from other devices with the same Room ID, to add more people.

Step 9: Test Controls and Adaptive Bitrate

Test the 2 conference features on the iPhone:

Camera and microphone: tap the buttons at the bottom of the screen. Each button turns red while its device is off.
Adaptive bitrate: each tile shows that participant’s resolution and bitrate. Open Settings → Developer → Network Link Conditioner on the iPhone, choose the 3G profile and turn it on. The resolution and bitrate values drop, then recover when Network Link Conditioner is off.

How Do You Fix the 8 Common Setup Errors?

Each of the 8 setup errors below has a single fix, covering server reachability, room mismatches, permissions, code signing, stream IDs and CocoaPods. The table has 8 rows (one per error) and 2 columns: the observed problem and the fix.

Problem	Fix
The app never connects	Repeat Step 1. On a physical iPhone, localhost refers to the phone itself; use the server’s IP address or domain.
Browser participants do not appear on the iPhone	Use the same application (WebRTCAppEE) and the same room on every device. Open multitrack-conference.html, not conference.html, because the Flutter SDK joins track-based SFU conferences and the browser page has to match that room type.
Browser tabs cannot access the camera	The page is loaded over http:// from a host other than localhost. Install an SSL certificate and use port 5443; the guide to enabling SSL certificates covers the domain setup. Option C in Step 8 covers development-only testing.
The app cannot reach a server on the local network	The local network permission was denied. Enable the app under Settings → Privacy & Security → Local Network.
Xcode: “cannot be registered to your development team”	The bundle identifier is taken. Change the bundle identifier to a unique value (Step 3).
“This app can only be launched from Flutter tooling”	Debug builds start only through flutter run. Start the app from the Mac instead of tapping the icon.
invalidStreamName error	Use only English letters and numbers in stream IDs.
pod install fails with XCLocalSwiftPackageReference	CocoaPods is older than 1.16. Upgrade with brew upgrade cocoapods (Homebrew installs) or sudo gem install cocoapods (RubyGems installs).

What Can You Build Next?

Your conference app works. From here you can:

Run it on other platforms. Flutter builds the same code for Android, the web, Windows, macOS and Linux, so you don’t rewrite the call screen for each one.
Make it interactive. Send chat messages, reactions or other in-call events over WebRTC data channels, without touching audio or video.
Try the other SDK modes. The same sample app includes Publish & Play for one-to-many streaming and P2P for direct calls. The Flutter SDK documentation covers each mode.

Frequently Asked Questions

Does Ant Media Server Community Edition support Flutter video conferencing?
No. Flutter video conferencing requires Ant Media Server Enterprise Edition. With Community Edition, the Flutter SDK supports WebRTC publishing only; WebRTC playback, conference rooms and data channels are Enterprise Edition features.

Which WebSocket URL does the Flutter app use?
The Flutter app uses ws://AMS_HOST:5080/APP_NAME/websocket without SSL and wss://AMS_HOST:5443/APP_NAME/websocket with SSL. This tutorial uses WebRTCAppEE as the application name. Production apps use wss:// on port 5443.

**Why does the browser use multitrack-conference.html?
**The browser uses multitrack-conference.html because the Flutter SDK joins multitrack conference rooms. The Flutter SDK’s Room ID parameter targets WebRTC multitrack conference mode, and a browser participant appears on the iPhone only when the browser page joins the same room type.

**How does adaptive quality work in the conference?
**Adaptive quality lowers each stream’s resolution and bitrate when bandwidth drops and raises both when bandwidth recovers. The tile captions display the current values, and the relationship between bitrate and resolution explains why both numbers move together.

**Does the conference work when participants are on different networks?
**Yes. Participants on different networks connect through STUN, and participants behind restrictive firewalls require a TURN server. The Flutter SDK’s connect() method accepts a custom ICE server list. The guide to NAT traversal setup covers TURN configuration.

**Does the same Flutter app run on Android?
**Yes. The same SampleProject runs on Android without code changes. Enable developer options and USB debugging on the Android device, connect the device, and run the project with flutter run or from Android Studio.

**How do you secure Flutter conference rooms?
**Flutter conference rooms are secured with stream tokens passed through the token parameter of connect(). Ant Media Server validates the token before allowing publish or play. JWT stream security adds time-based expiration to each token.

What is the difference between the Flutter SDK and the native iOS SDK?
The Flutter SDK builds one codebase for iOS and Android; the native iOS SDK builds iOS-only apps in Swift. Teams with an existing Swift app start from the native iOS SDK. Both SDKs ship free with an Enterprise Edition license.

Conclusion

MoQ: The Next Big Shift in Ultra-Low Latency Streaming?

Ankush Banyal — Wed, 20 May 2026 10:46:44 +0000

Media over QUIC (MoQ) is starting to become one of the most interesting shifts in real-time streaming infrastructure.

For years, the industry has been balancing between:

Ultra-low latency with WebRTC
Scalability with HLS/CDN architectures

MoQ introduces a different direction — combining QUIC-based transport with scalable real-time delivery models that can potentially reduce infrastructure overhead while maintaining very low latency.

Why this matters:

Large-scale interactive streaming becomes more practical
Better transport efficiency compared to traditional approaches
Reduced dependency on heavy peer/session management
More flexibility for modern live experiences like esports, live shopping, auctions, and interactive broadcasts

At Ant Media, we’re actively exploring and supporting MoQ-based workflows alongside WebRTC and LL-HLS architectures.

One important point:
MoQ is still evolving, and adoption will require ecosystem changes — especially around playback support and player integrations. But the direction is extremely promising for the future of scalable real-time media delivery.

The streaming stack is evolving fast:
RTMP → HLS → WebRTC → MoQ

Excited to see where the ecosystem goes next 🚀

MoQ #MediaOverQUIC #WebRTC #LowLatencyStreaming #StreamingInfrastructure #LiveStreaming #QUIC #RealtimeMedia #AntMedia #OTT #Esports

Ant Media Server v3.0 Is Here — AI-Powered Streaming, AV1, MoQ & More 🚀

Malti Thakur — Wed, 13 May 2026 10:34:31 +0000

Ant Media Server v3.0 Released 🚀

Ant Media Server
has officially launched v3.0, bringing major upgrades for low-latency streaming and AI-powered video applications.

Highlights of v3.0
🔹 AV1 Codec Support

Better compression, lower bandwidth usage, and improved video quality for modern streaming workflows.

🔹 Media over QUIC (MoQ)

New MoQ plugin support enables next-gen ultra-low-latency media delivery using QUIC transport.

🔹 AI Plugin

A powerful new AI plugin lets developers process live video streams with external Python AI modules for:

Object detection
Face recognition
Real-time analytics
Smart surveillance
🔹 Improved LL-HLS & SRT

Enhanced LL-HLS playback and better SRT re-streaming support for professional broadcasting pipelines.

🔹 Security & Stability

v3.0 also includes architecture cleanup, deprecated API removal, HSTS support, and several stability improvements.

Why It Matters

Ant Media Server v3.0 focuses on the future of streaming:

AI-powered video workflows
Modern low-latency protocols
Efficient codecs
Scalable real-time delivery

A solid update for developers building WebRTC, live streaming, and real-time video applications.

👉 Official release: https://antmedia.io/ant-media-server-v3-0-release/

What is Simulcasting in Live Streaming?

Amar Thodupunoori — Wed, 29 Apr 2026 09:56:36 +0000

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.

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.

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](Note: YouTube does not accept streams without audio — make sure your encoder includes an audio track)
Twitch — [nearest-ingest-endpoint]/[stream-key](get your nearest ingest server from the Twitch Ingest Server list)
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:

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-endpointto add a destination
DELETE /LiveApp/rest/v2/broadcasts/{streamId}/rtmp-endpoint?endpointServiceId={dataId} to remove one.
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.

What is Simulcasting in Live Streaming?

Mohammad Owais K. — Wed, 15 Apr 2026 09:00:06 +0000

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.

What is Simulcasting and How Does It Differ from Standard Streaming?

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

Amar Thodupunoori — Wed, 08 Apr 2026 10:55:56 +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.

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.

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.

MPEG-DASH Streaming: Complete Guide to Adaptive Video Delivery over HTTP

Mohammad Owais K. — Wed, 01 Apr 2026 09:16:28 +0000

Every viewer expects smooth, buffer-free video — whether they are watching a live sports broadcast on a phone or streaming a feature film on a smart TV. Behind the scenes, the protocol handling that delivery determines whether the experience holds up under real-world network conditions. MPEG-DASH (Dynamic Adaptive Streaming over HTTP) is the only ISO-ratified international standard designed specifically for this job. Ratified in 2012 under ISO/IEC 23009-1 and revised most recently in 2022, MPEG-DASH powers adaptive video delivery for Netflix, YouTube, and thousands of broadcast-grade streaming platforms worldwide.

This guide walks through how the MPEG-DASH protocol works at a technical level, where it differs from Apple’s HLS, what makes its codec-agnostic design valuable for modern streaming architectures, and how Ant Media Server implements DASH delivery with low-latency CMAF packaging, GPU-accelerated transcoding, and multi-protocol ingest support.

DEV Community: Ant Media

How to run MoQ in AWS for sub-second live streaming at scale

Why MoQ exists

Running it on AWS

Publish, and watch it back

What is running now

What you can add to it

Why run it on AWS specifically

Measured on one c5.xlarge

Try it on AWS

Stream IP Cameras on AWS: RTSP to WebRTC in 4 Steps

Step 1: Launch the server

Step 2: Open the panel

Step 3: Add your camera

Step 4: Watch it live

Why WebRTC instead of HLS?

Controlling PTZ cameras

Capacity: one setting, twelve times the cameras

Wrapping up

WebRTC Video Streaming: How a Live Broadcast Reaches 0.5s Latency [2026 Update]

What is WebRTC?

Why WebRTC Video Streaming Is Transforming Live Streaming

Key Advantages of WebRTC Video Streaming

How Does WebRTC Live Streaming Work for a One-to-Many Broadcast?

What Latency Does WebRTC Video Streaming Actually Deliver?

What Pushes WebRTC Latency Above 0.5 Seconds?

RTMP to WebRTC Migration: Why It's Essential

Which Software Publishes a WebRTC Video Stream?

Why Does a WebRTC Video Stream Fail to Connect or Play?

WebRTC Video Streaming with Ant Media Server

Why Choose Ant Media for WebRTC?

Frequently Asked Questions

Conclusion

WebRTC Servers Explained: Signaling, TURN, SFUs and How to Set One Up

What a WebRTC server does

Do you need one?

Mesh, MCU or SFU

Ingest: getting a stream to the server

Delivery latency matters more than ingest

Comparing eight open-source servers

Self-hosted vs managed API

Hardware sizing

Security basics

Setting up a first stream

Takeaway

Flutter Video Conference App for iOS, Android, Web and Desktop.

Why Flutter for a Video Conference App?

What Do You Need Before You Start?

Step 1: Confirm the iPhone Reaches Ant Media Server

Step 2: Clone the Flutter SampleProject

Step 3: Sign the App in Xcode

Step 4: Enable Developer Mode on the iPhone

Step 5: Run the App on the iPhone

Step 6: Connect the App to the WebSocket URL

Step 7: Join the Conference Room from the iPhone

Step 8: Add 3 Browser Participants

Step 9: Test Controls and Adaptive Bitrate

How Do You Fix the 8 Common Setup Errors?

What Can You Build Next?

Frequently Asked Questions

Conclusion

Flutter Video Conference App for iOS, Android, Web and Desktop

Table of contents

Why Flutter for a Video Conference App?

Step 1: Confirm the iPhone Reaches Ant Media Server

Step 2: Clone the Flutter SampleProject

Step 3: Sign the App in Xcode

Step 4: Enable Developer Mode on the iPhone

Step 5: Run the App on the iPhone

Step 6: Connect the App to the WebSocket URL

Step 7: Join the Conference Room from the iPhone

Step 8: Add 3 Browser Participants

Step 9: Test Controls and Adaptive Bitrate

How Do You Fix the 8 Common Setup Errors?

What Can You Build Next?

Frequently Asked Questions

Conclusion

MoQ: The Next Big Shift in Ultra-Low Latency Streaming?

MoQ #MediaOverQUIC #WebRTC #LowLatencyStreaming #StreamingInfrastructure #LiveStreaming #QUIC #RealtimeMedia #AntMedia #OTT #Esports

Ant Media Server v3.0 Is Here — AI-Powered Streaming, AV1, MoQ & More 🚀