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
5080and5443(panel and HTTPS) and UDP50000-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
