DEV Community: Malti Thakur

How to Get Sub-Second Latency from OBS Using WHIP on AWS published.

Malti Thakur — Fri, 30 Oct 2026 08:58:35 +0000

Disclosure: I work at Ant Media, and this walkthrough uses Ant Media Server. The same WHIP steps in OBS apply to any WHIP-compatible server.

OBS over RTMP usually puts viewers 2 to 5 seconds behind you. That's fine for a normal broadcast. It's a problem for auctions, live classes, remote camera control, or anything where a person has to respond to what they see.

WHIP (WebRTC-HTTP Ingestion Protocol, RFC 9725) is the fix. OBS has supported it since v30, so you don't need new software on the encoder side. You change the service and the URL, and glass-to-glass latency drops below 0.5 seconds.

Here's a setup on AWS, start to finish.

What you need

An AWS account
OBS 30 or newer
About ten minutes

1. Launch the server

Subscribe to Ant Media Server on AWS Marketplace (there's a 7-day free trial of the software; normal EC2 charges still apply):

Open View purchase options, choose Usage based, and click Subscribe.
Go to Launch your software and choose Launch from EC2 Console.
Pick the latest version and a region, then name the instance and choose an instance type and key pair.
Keep the default security group for now and launch.

Nothing needs installing because the software is already running on the instance.

2. Enable SSL

A fresh instance serves plain HTTP on port 5080. Log in at http://<server-ip>:5080 with the username JamesBond and your EC2 instance ID as the password.

Then go to Server Settings → TLS/SSL, pick the free antmedia.cloud subdomain (or use your own domain), click Configure SSL, and apply the restart. When it comes back you'll have HTTPS on port 5443.

3. Configure OBS

In Settings → Stream, set the service to WHIP and use this as the server URL:

https://<your-domain>:5443/live/whip/<streamId>

live is the default application name, and streamId can be anything. The stream is created when OBS connects. Leave the bearer token empty unless you've turned on stream security, then hit Start Streaming.

4. Play it back

https://<your-domain>:5443/live/play.html?id=<streamId>

That plays over WebRTC. Add &playOrder=hls to check the HLS output of the same stream.

If it doesn't work

Symptom	Likely cause
OBS says "streaming", no video	UDP 50000–60000 is blocked in the security group
Fails immediately on start	Wrong endpoint URL
No WHIP option in OBS	OBS is older than v30
404	App name in the URL doesn't match (it's case-sensitive)

The UDP one catches almost everyone. Signalling goes over HTTPS and succeeds, so OBS looks happy, but the media has no path through.

RTMP or WHIP?

Use RTMP if nobody needs to react to the video. It works with almost every encoder. Use WHIP when delay matters and you're okay requiring OBS 30+, FFmpeg or a browser as the publisher.

Full version with screenshots: antmedia.io/whip-server-aws. You can also try publishing from a browser first on the public WHIP test page.

Ready to try it? Start the 7-day free trial on AWS Marketplace.

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.

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/

Ant Media Server v2.17.0 — SSAI, Web SDK v2 & Low-Latency Streaming at Scale

Malti Thakur — Wed, 18 Mar 2026 10:35:54 +0000

If you’re working with real-time video or live streaming, the new release of Ant Media Server v2.17.0 is worth a look.

👉 https://antmedia.io/ant-media-server-v2-17-0/

🔥 What’s new?

💰 Server-Side Ad Insertion (SSAI)
Monetize your streams without disrupting playback — ads are stitched directly into the stream.

⚙️ Web SDK v2
Cleaner API, better reconnection handling, and modern async/await support.

⚡ Improved Low-Latency HLS (LL-HLS)
Scale to larger audiences while keeping latency low (≈2–5s).

🧠 Why it matters

This update focuses on what developers actually need:

Better monetization
Smoother developer experience
More reliable scaling Whether you’re building a live streaming app, webinar platform, or real-time product, these upgrades make things easier.

🚀 Enhance Your Android Live Streams with DeepAR & Custom Overlays Using Ant Media SDK

Malti Thakur — Wed, 04 Mar 2026 11:06:53 +0000

Live streaming has come a long way. Viewers today expect engaging, interactive experiences — not just a static camera feed. With the Ant Media Android SDK, you can bring Augmented Reality (AR) effects and branded overlays right into your live streams. In this post, we’ll explore how to add DeepAR effects and Custom Canvas Overlays to Android live streams using Ant Media Server’s WebRTC SDK.

🔧 Getting Started

There are two sample activities available in the companion GitHub repo:

DeepARActivity.java — for AR effects

CustomCanvasActivity.java — for custom overlays

📌 To get started:

Clone the sample:

git clone https://github.com/USAMAWIZARD/AntMedia-DeepAR-And-Overlay

Build and run on your Android device.
Start streaming with dynamic effects or branded overlays!

🪄 Section 1: DeepAR Activity — Augmented Reality for Live Streaming

What is DeepAR?

DeepAR is an AR SDK for real-time face tracking, filters, and visual effects. When integrated with the Ant Media Server SDK, you can stream AR-enhanced video with ultra-low latency to your viewers.

*How It Works
*

The camera captures the video feed.
Frames pass through the DeepAR SDK.
DeepAR applies selected AR effects.

Processed frames are sent via WebRTC to the Ant Media Server and streamed live to viewers.

Example effects include:

Viking helmets
Neon devil horns
Playful AR elements

*Code Snippet — Initialize DeepAR
*

deepAR = new DeepAR(this);
deepAR.setLicenseKey("your-license-key");
deepAR.initialize(this, this);

initializeEffects();
setupCamera();
setupStreamingAndPreview();

*WebRTC Client Setup
*

webRTCClient = IWebRTCClient.builder()
    .setServerUrl("wss://test.antmedia.io/LiveApp/websocket")
    .setActivity(this)
    .setVideoSource(IWebRTCClient.StreamSource.CUSTOM)
    .setWebRTCListener(createWebRTCListener())
    .setInitiateBeforeStream(true)
    .build();

*Camera Frame Processing
*

imageAnalysis.setAnalyzer(ContextCompat.getMainExecutor(this), image -> {
    try {
        feedDeepAR(image);
    } finally {
        image.close();
    }
});

You can also cycle through effects with simple UI controls.

*🎨 Section 2: Custom Canvas Activity — Branded Overlays
*
While AR effects are fun, sometimes streams need branding elements, such as:

Logos
Watermarks
Text captions

That’s where Custom Canvas Overlays come in.

*Built-in Overlay Types
*

Image Overlay
Use your own logo or branding graphic, positioned anywhere on the screen.
Text Overlay
Show custom text like titles or hashtags, with adjustable font size and color.

How It Works
CameraX captures frames.
An OpenGL ES renderer composites overlays.
Final frames are streamed via WebRTC. *Sample Overlay Setup *

imageProxyRenderer = new ImageProxyRenderer(webRTCClient, this, surfaceView, new CanvasListener() {
    @Override
    public void onSurfaceInitialized() {
        // Image overlay
        logoOverlay = new Overlay(getApplicationContext(), R.drawable.test, 0.8f, 0.8f);
        logoOverlay.setSize(0.2f);

        // Text overlay
        textOverlay = new Overlay(getApplicationContext(), "Hello", 64, Color.RED, 0f, -0.3f);
        textOverlay.setSize(0.12f);
    }
});

*🚀 Why Ant Media Server?
*
Using WebRTC with Ant Media Server gives you:

✔ Ultra-low latency streaming
✔ Scalable streaming to thousands of viewers
✔ Adaptive bitrate support
✔ Cross-platform playback on any device or browser

*🏁 Wrap Up
*
Whether you want fun AR effects or professional overlays, the Ant Media Android SDK gives you powerful tools to elevate your Android live streaming.

*👉 Clone the project and start experimenting!
*
Would you like a formatted Markdown version with images and GitHub links ready for DEV.to (so it looks even better when published)? Just let me know!
👉 Check the original tutorial here: https://antmedia.io/deepar-and-custom-overlay-with-ant-media-android-sdk/

Build a WebRTC Streaming App in Flutter Using Ant Media SDK

Malti Thakur — Wed, 04 Feb 2026 09:34:05 +0000

WebRTC enables real-time, ultra-low latency audio and video streaming. While it’s widely used on the web, integrating WebRTC into Flutter applications can be challenging without the right tools.

In this post, I’ll walk you through how to use the Ant Media WebRTC Flutter SDK to publish and play live streams in a Flutter app with minimal setup.

What you’ll learn

How to create a Flutter project
How to add Ant Media’s WebRTC Flutter SDK
How to publish a live WebRTC stream
How to play the stream in your app

Why Ant Media WebRTC Flutter SDK?

Cross-platform support (Web & Mobile)
Ultra-low latency streaming
Easy API integration
Production-ready WebRTC infrastructure Getting Started

First, create a Flutter project and make sure Flutter Web is enabled.

Then add the SDK to your pubspec.yaml:

dependencies: ant_media_flutter: ^1.4.1

Run:

flutter pub get
Publish a Stream

Using the SDK, you can connect to Ant Media Server and start publishing a WebRTC stream by setting the connection type to Publish.

Play a Stream

To play the live stream, simply change the connection type to Play and run the app again.

That’s it 🎉
With just a few steps, you can build real-time video streaming applications such as:

Live events
Online education platforms
Video conferencing apps
Interactive streaming solutions

👉 Full tutorial:
https://antmedia.io/webrtc-flutter-sdk/

Join the Ant Media AI Hackathon | Feb 25–28, 2026

Malti Thakur — Fri, 16 Jan 2026 11:49:44 +0000

Ant Media AI Hackathon: Build AI-Powered Real-Time Streaming Apps

Malti Thakur ・ Jan 16

#hackathon #ai #streaming #webrtc

[Boost]

Malti Thakur — Fri, 16 Jan 2026 11:47:54 +0000

Ant Media AI Hackathon: Build AI-Powered Real-Time Streaming Apps

Malti Thakur ・ Jan 16

#hackathon #ai #streaming #webrtc

Ant Media AI Hackathon: Build AI-Powered Real-Time Streaming Apps

Malti Thakur — Fri, 16 Jan 2026 10:58:38 +0000

The Ant Media AI Hackathon is an online hackathon focused on building
AI-powered real-time streaming solutions using Ant Media Server.

📅 Hackathon Dates: Feb 25–28, 2026

🗓 Registration Deadline: Jan 25, 2026

🏆 Prizes: $5,000 | $3,000 | $2,000

👥 Participation: Individuals or teams (up to 5 members)

Participants can build projects such as:

Speech-to-text or translation for live streams
Real-time video effects
AI-driven media generation
Detection, analytics, or AR/VR streaming features

👉 Learn more and register here:
https://antmedia.io/ai-hackathon/