Picture a modern surveillance deployment: two hundred cameras, a clean web dashboard, operators who want to pull up any feed from a laptop or a phone. Simple, in 2026 — except it isn’t. Getting a single live camera into a browser tab still tends to involve a plugin, a relay server, or a transcoding hack held together with tape. The reason is a language barrier that was never fixed: your cameras speak RTSP, and no browser on earth speaks it back. Closing that gap — the RTSP to WebRTC problem — is the last mile of web-based surveillance, and it’s worth understanding exactly how we got here.

From a Wire in the Wall to Data on a Network

CCTV meant exactly what it says: closed-circuit television. A camera, a coax cable, a monitor in a back room. The picture was an analog signal on copper, and to see it you stood at the end of the wire. Add a recorder and you had a tape. Bulletproof — and completely chained to the building. The circuit was closed by design.

Then cameras grew a network port and became small computers. The picture stopped being a signal on a wire and became data on a network — in principle, viewable from anywhere. One problem stood in the way, and it still shapes everything: raw video is enormous. An uncompressed HD stream runs into gigabits per second. Nobody could store or ship that. The entire IP-video era depended on compression.

So the first thing worth understanding isn’t a protocol. It’s the squeeze.

Codecs: The Compression That Made IP Video Possible

A codec throws away what the eye won’t miss and sends mostly what changed between frames. H.264, standardised in 2003, is the one that made IP surveillance practical — it shrank video by orders of magnitude and got baked into camera chips everywhere, so encoding and decoding it is cheap and universal. It is still the common tongue of video.

H.265 (HEVC), from 2013, does the same job roughly twice as efficiently. Surveillance seized on it for two reasons that dominate this industry: 4K sensors and 24/7 recording. When you store hundreds of cameras around the clock, halving the bitrate halves the storage bill. H.265 was made for that trade. Keep it in mind — it comes back as the villain of this story.

Compression solved storage and transport. But a viewer still needs a way to say “play.” That’s where RTSP comes in.

RTSP: The Remote Control Built for a World Without Browsers

RTSP — Real-Time Streaming Protocol, from 1998 — is essentially the remote control for a live stream: play, pause, teardown. The compressed video rides alongside it, over TCP or UDP. The detail that matters is who RTSP was built for: dedicated players and recorders — VLC, an NVR — machines on the same network, fluent in the camera’s language. It assumes a serious, persistent client. For that world it is excellent, and it became the universal standard: virtually every IP camera exposes an RTSP stream.

That produced the setup the industry has run on for two decades. Camera speaks RTSP and H.264. It feeds an NVR or a VMS — the dedicated recorder-and-management systems the surveillance world is built around — which stores everything and paints it onto a wall of monitors in a control room. A closed loop of machines that grew up together, all fluent in the same protocol. It just worked.

And then the people who watch the cameras stopped wanting to sit in the control room.

The Browser Gap: Why the Web Was Never Invited

Operators wanted feeds on a laptop, a phone, a dashboard — from anywhere, with nothing to install. And the web stack hit a wall, because the browser never learned to speak RTSP. Not by accident: browsers deliberately dismantled the plugin era — Flash, ActiveX, all of it — for security, and RTSP was never a web protocol to begin with. So the moment you drag surveillance out of the control room onto the open web, the camera is shouting in RTSP and the browser doesn’t understand a word.

For years the industry papered over this. Vendor-specific desktop apps. Browser plugins, until those died. Transcoding the whole feed to HLS — which works and plays anywhere, but lags five to ten seconds behind reality: fine for reviewing footage, useless when you’re watching a door right now. Relay servers. Every option was a workaround for the same missing handshake.

What finally changed isn’t a better workaround. It’s that the browser learned to speak live video on its own.

RTSP to WebRTC: Closing the Gap

WebRTC is the browser’s native real-time video engine — the same technology behind every video call you take. It ships in every major browser, needs no plugin, and is built for sub-second latency. For the first time, the web can carry genuinely live video by itself.

So the fix is a translator in the middle: a media server that pulls the camera’s RTSP stream and re-wraps it as WebRTC the browser can play. When it works cleanly, the result is a camera live in a browser tab in well under a second, from any device, with nothing installed. That is the shift — surveillance walking out of the locked control room onto the open web.

But “when it works cleanly” is carrying a lot of weight in that sentence. Because the codec you chose to save on storage is about to send you a bill.

The Codec Trap: Where the Real Cost Hides

Here is the catch that separates a demo from a deployment. Camera chips only ever encode H.264 or H.265 — never the codecs the web grew up on, like VP8, VP9, or AV1. And browser support over WebRTC is uneven: H.264 is universal, but H.265 is accepted only by some browsers, on some hardware — Chrome and Safari have added it recently, Firefox hasn’t, and it depends on the device underneath. That splits every stream into two very different paths.

If the camera sends H.264, the translator can pass it through untouched — no re-encoding. Latency stays in the low hundreds of milliseconds, and the CPU cost is trivial. This is the clean case.

If the camera sends H.265 — which the modern 4K cameras you bought to save storage almost certainly do — the translator has to transcode it to H.264 for the browser to accept it. Transcoding means fully decoding and re-encoding every frame of every stream. On one camera, unnoticeable. On two hundred cameras, it is a server farm — real CPU, real money, and added latency on every feed.

That is the whole game. The codec that halved your storage bill can quietly multiply your live-streaming bill. An architecture that ignores this looks fine in a one-camera demo and falls over at deployment scale.

Which means a clean design isn’t about getting one camera on screen. It’s about getting all of them there without a transcode bill that eats the product.

What a Clean RTSP-to-WebRTC Architecture Looks Like

Five principles separate a real pipeline from a duct-taped one.

Pass through by default. If a camera speaks H.264, never re-encode it. Passthrough is cheap and near-instant; transcoding is the expensive exception, not the default.

Transcode only when forced, and budget for it. H.265 streams that must reach non-supporting browsers get transcoded — but treat that as a known cost per stream, not a hidden surprise, and push cameras to a browser-friendly profile where you can.

Separate the live path from the recording path. Store the original high-efficiency H.265 for archive and storage savings; transcode only the live view a human is actually watching. You rarely need every camera transcoded at once — only the ones on screen.

Fan out, don’t duplicate. One pull from the camera, forwarded to many viewers, so ten operators watching one feed don’t mean ten pulls on the camera.

Offer HLS as the fallback, not the default. For a mobile viewer on a bad network, or a wall of dozens of low-priority feeds, higher-latency HLS is a reasonable trade. Keep WebRTC for the live, interactive views.

Open-source media servers like go2rtc and MediaMTX implement much of this — H.264 passthrough, RTSP-to-WebRTC conversion, HLS output, and automatic transcoding when a codec won’t cross. They’re the fastest way to see the architecture working.

Getting one camera live is a weekend project. Getting a whole site live, 24/7, at a cost that doesn’t sink the product, is an infrastructure decision — which comes down to build, buy, or deploy.

Build, Buy, or Deploy

Build on open source. go2rtc or MediaMTX, run and scaled by you. Maximum control, and you own the transcode economics directly. Right when live video is core to your product and you have the team to operate a media pipeline.

Use a managed cloud relay. Fastest to a working browser view, no infrastructure to run — but your camera feeds route through a third party, and you pay per stream as you grow. Right when speed matters more than owning the path.

Deploy a commercial platform. A full media stack — RTSP ingest, passthrough, transcode, WebRTC fan-out, recording — delivered as something you run on your own infrastructure or as a managed cloud deployment, under a flat license. Samvyo is one such option; it’s SFU-based and deploys on-premise or on your chosen cloud. Right when the media path has to live inside your own product and infrastructure. Where it doesn’t fit: a handful of cameras or a hobby project — open source or a relay is more than enough.

The Bottom Line

The gap between an RTSP camera and a web browser is permanent — the browser is never going to speak the camera’s language. What changed is that WebRTC finally lets the browser speak live video, so the whole problem reduces to a good translator in the middle. And a good translator has one defining trait: it passes H.264 through untouched and transcodes only when the codec forces it, because that single decision is what separates a system that works on one camera from one that works on two hundred. Name the codec reality, and the architecture writes itself.

What’s Next?

Same live-video problem, different world? Solving this for moving vehicles instead of fixed cameras — dashcams, cellular uplinks, and a command centre — is a related but distinct architecture. The companion piece on fleet video streaming walks that version, packet by packet: link.

Frequently Asked Questions

Can a web browser play an RTSP stream directly?

No. Browsers don’t implement RTSP and never will — it was built for dedicated players, not the web. You need a media server to convert RTSP to WebRTC (for live, low-latency viewing) or to HLS (for higher-latency, universal playback) before it reaches the browser.

What’s the lowest-latency way to view an IP camera in a browser?

RTSP to WebRTC with H.264 passthrough. When the camera already sends H.264, no re-encoding is needed and latency stays in the low hundreds of milliseconds — effectively real time.

Does WebRTC support H.265/HEVC?

Only partially. H.264 is universally supported over WebRTC; H.265 is accepted by some browsers on capable hardware (recent Chrome and Safari) but not others (Firefox). For reliable cross-browser live view, H.265 camera streams usually have to be transcoded to H.264.

Why is transcoding a problem at scale?

Transcoding fully decodes and re-encodes every frame of every stream, which is CPU-intensive. One camera is nothing; hundreds of simultaneous transcodes become a serious server cost — the hidden expense in browser-based surveillance, and the reason passthrough matters.

go2rtc vs MediaMTX — which should I use?

Both are open-source media servers that convert RTSP to WebRTC with H.264 passthrough and low latency. go2rtc is lightweight and popular in camera and home-automation setups; MediaMTX supports more protocols (RTSP, RTMP, HLS, SRT, WebRTC) on a single stream. Either is a solid starting point.

WebRTC or HLS for live surveillance?

WebRTC for anything a human watches live and acts on — sub-second latency. HLS only when a multi-second delay is acceptable in exchange for simpler, universal playback, such as low-priority feeds or poor mobile networks.

Subscribe to VidBlogs