If you are here from the business version, you are in the right place.
The business version made the case for augmenting an existing estate instead of ripping it out. From the architecture chair, augmenting sounds like the easy half: the camera already exposes an RTSP URL, so point a media server at it, convert to WebRTC, done. It works in the demo. Then you scale past a couple of viewers and something starts dropping — sometimes the live view, sometimes, alarmingly, the recording. The reason is that an IP camera is not a media server, and the NVR already holds a connection to it around the clock. So the first real decision in NVR live streaming is not which media server or which browser API. It is where you tap the stream — because that one choice sets your connection budget, your CPU cost, and whether recording and live view can coexist at all.
The camera is not a media server
Open up what you are actually pulling from. An IP camera is a small embedded system: an image sensor, a hardware encoder ASIC that turns raw frames into H.264 or H.265, a modest SoC, and a lightweight network stack running an RTSP server. That RTSP server answers DESCRIBE, SETUP, PLAY — but it was built to serve a recorder and maybe an operator, not a fan-out audience. Each concurrent session costs it encoder access, packetization, and socket state it has very little of to spare, so the main stream typically supports only a handful of simultaneous connections — often single digits, and model-dependent — before frames start stuttering or new sessions are refused.
Now remember who is already sitting in one of those seats: the NVR, holding a session continuously to record every frame. That connection is not optional and not interruptible — it is the compliance-critical job of the whole system. So every consumer your live layer adds is competing for the few seats left beside the recorder. Point ten browsers at the camera directly and you don't get ten viewers; you get a starved encoder and, in the worst case, a recorder that loses its stream.
So before you point anything at the camera, you have to count seats — and decide which one you're taking.
Three places to tap, three trade-offs
There are exactly three points you can pull a live feed from in a recording deployment, and choosing among them is the core of the architecture.
The camera main-stream is the full-resolution feed the recorder archives. Tapping it directly gives you the best image and the lowest latency, but it spends the camera's scarcest resource and puts you in direct contention with recording. Viable only at small viewer counts — or behind a single pull that fans out, which we'll get to.
The camera sub-stream is the second, lower-resolution feed most IP cameras encode in parallel (D1 or CIF, low bitrate) — and it is frequently already H.264 even when the main stream is H.265. It is purpose-built for live preview, it costs the camera far less, and pulling it leaves the main stream entirely to the recorder. For most live browser and mobile use, this is the cleanest coexistence you can get off the camera itself.
The NVR or VMS re-stream flips the topology: many recorders expose an RTSP or ONVIF re-stream of what they are already ingesting, so your live layer pulls from the recorder instead of the camera. The camera then sees a single consumer — the NVR — no matter how many people watch. The cost is an extra hop of latency and a dependency on the NVR's re-stream capacity and licensing, which varies widely by vendor.
Whichever tap point you choose, the golden rule underneath all three is the same: the source — camera or NVR — should be pulled once, not once per viewer.
Pull once, fan out — the core of NVR live streaming
The move that makes any of the three tap points scale is to put a media server between the source and the audience and pull exactly one session from the source. That server ingests the single stream and forwards it to every browser watching, selectively — the selective-forwarding model — without opening a new pull on the camera for each viewer. One of the camera's scarce seats is spent, and one only, regardless of whether two operators are watching or two hundred.
This is the difference between a design that respects the camera's limits and one that fights them. Without a fan-out layer, ten viewers means ten pulls, and you blow the connection cap and starve the recorder — exactly the failure the previous section warned about. With it, viewer count is decoupled from source load entirely: the camera feels one consumer, the media server absorbs the multiplication, and scaling the audience becomes a problem on your infrastructure rather than on a $150 embedded device bolted to a wall. This single-pull, many-viewer property is precisely what SFU-based infrastructure exists to provide.
Fan-out solves the count. But live view and recording still want two different things from the same bytes — and where you split them decides your CPU bill.
Coexisting with 24/7 recording: two paths, one source
Recording and live view have opposite priorities. The recorder wants the original, highest-fidelity stream — full-resolution H.265, untouched — archived continuously, because detail is evidence and efficiency is storage. Live view wants the opposite: a low-latency, browser-renderable H.264 feed it can show right now, where a slightly softer image is completely acceptable. Try to serve both from the same main-stream tap and you are forced into one of two bad places: double-pulling the main stream (two scarce seats), or transcoding the archive-grade H.265 down to browser H.264 in real time — the exact transcode tax that turns one camera into a server farm at scale.
The clean topology separates the two paths at the source rather than downstream. Let the recorder keep the main-stream, untouched, doing the passthrough archival it does cheaply. Give the live layer the sub-stream — already low-bitrate and often already H.264, so it frequently sidesteps the transcode entirely — or the NVR re-stream. You end up with two independent paths off one device: a high-fidelity recording path the browser never touches, and a lightweight live path the recorder never notices. Split at the source, and the CPU-heavy conflict simply never arises.
With the source chosen and the two paths separated, the last coexistence question is the one that actually bites in production: what happens when something drops.
Failure, reconnection, and a shared source
Cameras reboot. PoE switches cycle. Wireless links flap. When a camera drops, both the recorder and the live layer lose it at once, and both will try to reconnect — and that is where a naïve live layer becomes dangerous. If your reconnection logic hammers the camera the instant it reappears, racing to re-establish live sessions, it can occupy the very connection seats the recorder needs to resume recording. You end up with a live-view feature that starves compliance-critical recording during exactly the window when something worth recording may be happening.
The discipline is a stated priority: recording is sacred, live view yields. Reconnection should use exponential backoff rather than a tight retry loop, so a returning camera is not stampeded. And the live layer should treat the recorder's session as reserved — reclaiming its own seats only after the recorder has re-secured its own. On a shared, connection-limited source, coexistence is not just about who taps where; it is about who gets the seat back first when the source returns.
Put the tap decision, the single-pull fan-out, the split paths, and the reconnection priority together, and coexistence stops being luck and becomes a topology you can draw.
Build, buy, or deploy
Getting one existing camera into a browser is a weekend. Making a live layer coexist cleanly with a recording estate — across the right tap points, single-pull fan-out, split paths, and recording-priority reconnection — is an infrastructure decision.
Build on open source. Media servers like go2rtc and MediaMTX ingest RTSP from a camera or an NVR, handle sub-streams, pass H.264 through untouched, and convert to WebRTC for the browser. What you build and operate on top is the coexistence logic: tap-point selection, fan-out orchestration, and the recording-priority reconnection. Right when the live layer is core to your product and you have the media engineers.
Use a managed relay. A hosted service pulls from your site and serves the browser — fastest to live, least to run. You still choose the tap point on your side; they own the cloud path and the per-stream cost. Right when speed matters more than owning the media path.
Deploy a platform you run. The full media stack — RTSP ingest from camera or NVR, sub-stream handling, single-pull fan-out, WebRTC delivery — delivered as something you run on-premise or as a managed cloud deployment, under a flat license, so feeds stay inside infrastructure you control. Samvyo is one such option; it is based on SFU architecture, which is what supplies the single-pull, many-viewer property this whole design leans on. Where it does not fit: a handful of cameras with a couple of viewers, where a media server alone already covers it and a full platform is over-engineering.
Three sourcing paths, one axis — how much of the coexistence layer you want to own versus rent.
The Bottom Line
The NVR already took the good seat, and that reframes the whole problem. Live browser video on an existing estate is not a media-server question, it is a stream-source topology question: tap the sub-stream or the NVR re-stream rather than fighting the recorder for the main-stream, pull the source exactly once and fan out to every viewer, split the recording and live paths at the source so the transcode conflict never arises, and make reconnection yield to recording when the camera returns. Get the tap right, and NVR live streaming stops being a fight with the recorder and becomes a clean layer beside it.
What's Next?
Want the decision-and-cost framing to forward to a non-engineer stakeholder? The companion business piece covers rip-and-replace versus augment, the sunk-CapEx math, and the egress cost of getting video out of the site: link to business version
And on the codec half of coexistence — why the sub-stream so often saves you a transcode, and what happens when it doesn't — see the RTSP-to-WebRTC piece: link to RTSP-to-WebRTC blog
Frequently Asked Questions
How many simultaneous connections can an IP camera handle?
Fewer than you'd expect. The main stream on many cameras supports only a handful of concurrent RTSP sessions — often single digits, and it varies by model — because each session costs the camera's encoder and network stack real resources. The recorder already holds one continuously, so the practical answer is to pull the camera once through a media server and fan out to viewers, rather than connecting each viewer directly.
Should I pull the live stream from the camera or the NVR?
It depends on your seat budget. Pulling the camera's sub-stream is the cleanest option off the camera itself — low cost, leaves the main stream to the recorder. When the camera's connections are exhausted or you want to offload it entirely, pull the NVR's RTSP/ONVIF re-stream instead, so the camera sees only the recorder as a consumer. Tapping the main stream directly is a last resort, viable only behind single-pull fan-out.
What is an NVR or ONVIF re-stream?
Many NVRs and VMS platforms can re-expose a stream they are already ingesting from a camera, over RTSP or ONVIF, so other systems pull from the recorder instead of the camera. It offloads the camera — which now serves a single consumer — at the cost of an extra latency hop and a dependency on the recorder's re-stream capacity and licensing.
How do I add live browser view without disrupting recording?
Separate the two paths at the source. Leave the recorder on the full-resolution main stream, and give live view the sub-stream or the NVR re-stream, so they don't compete for the same scarce connection. Then make reconnection yield to recording — use backoff, and let the recorder reclaim its session first when a camera returns — so live view can never starve the compliance-critical recording.
Does using the sub-stream avoid the H.265 transcode problem?
Often, yes. Many cameras encode the main stream in H.265 but the sub-stream in H.264, which browsers accept over WebRTC without re-encoding. Pulling the sub-stream for live view therefore sidesteps the transcode in a lot of deployments — though it's worth confirming per camera model, since the codec split isn't universal. The RTSP-to-WebRTC piece covers what happens when the browser can't take the codec directly.
Can a platform like Samvyo pull from an existing camera sub-stream or NVR?
Yes — that is the coexistence case. Based on SFU architecture, a platform like Samvyo ingests RTSP from a camera's sub-stream or an NVR re-stream, pulls the source once, and fans it out to many browser and mobile viewers without adding load per viewer. Deployed on-premise or as a managed cloud deployment, it keeps the live layer inside infrastructure you control while the existing recorder keeps doing the recording.
