Why an IP camera will not play in a browser

Paste an rtsp:// address into Chrome and no video plays. That is not a misconfiguration, and it is the first thing to understand before putting cameras on a plant screen.

RTSP was never a browser protocol

RTSP is a control protocol. It negotiates a session and tells a camera to start sending, but the video itself travels separately, usually as RTP over UDP or interleaved into the same TCP connection. Version 1.0 was specified in 1998 — and it is still the version cameras speak, though a standards-track version 2.0 followed in 2016.

No mainstream desktop browser implements it. The NPAPI plugins that once carried RTSP players in the browser — QuickTime, RealPlayer, VLC — stopped loading when Chrome dropped NPAPI in 2015 and Firefox followed in 2017. A browser plays video through its own media stack, which in practice means HLS or MPEG-DASH delivered over HTTP, or WebRTC, which uses its own real-time transport rather than HTTP. An RTSP camera speaks none of those.

So a translation step is not an optimization. Something has to receive RTSP and re-publish the video in a form a browser can open. The only real question is where that translation runs.

Where the translation runs decides three other things

It is tempting to treat this as a plumbing detail. It is not, because the location of that step determines what the client can see, how many sessions a camera is asked to serve, and what has to be reachable across the network in between.

Credentials

An RTSP URL commonly carries the camera username and password. If a component’s configuration carries that URL to the client, the credentials go with it — visible in page source to anyone who opens developer tools, even though the browser itself never speaks RTSP. Camera credentials are often shared across a whole site, so whether they are client-visible is worth deciding deliberately rather than by accident.

Session count

Cameras do not serve unlimited concurrent streams. The cap varies by model and by which stream profile is requested, and on many cameras the real constraint is the encoder and bitrate budget rather than a hard session limit. Either way the ceiling is finite, and if every screen connects directly then every operator watching the same camera pushes the camera closer to it. Where the translation runs determines whether the session count tracks your operator count or stays flat.

Network reachability

Direct playback requires every client to reach the camera network. Cameras are often deliberately isolated, and reversing that isolation to make a dashboard work undoes the reason the isolation existed.

Latency comes from the delivery format first

HTTP-based streaming works by cutting video into segments, publishing a playlist, and letting the player fetch segments in order. The player buffers before it can start, and with conventional segment durations that buffer is measured in seconds. The format sets the floor; cameras, network and gateway hardware then determine how far above that floor you actually land.

For camera views on a plant floor, seconds is usually an acceptable trade. You are answering “what is happening at the filler right now”, and a few seconds of delay rarely changes the answer. It is the wrong trade if you intend to control something while watching it, and tuning does not turn segmented HTTP delivery into a control-loop feedback path. If you need that, you need a different tool.

CVI-RTSP transcodes to HLS at the gateway and typically lands in the 3 to 10 second range, depending on cameras, network and gateway hardware. We publish that number rather than leave it vague. Sub-second figures over HLS come from heavily tuned low-latency variants on a purpose-built pipeline, not from the segmented delivery a gateway proxy performs.

What this means in practice

If you are putting cameras on a Perspective screen, the questions worth asking are not about video codecs. They are: does the client ever see camera credentials, how many sessions does each camera end up serving, does this require opening the camera network to clients, and what latency does the delivery format impose. Those four answers describe the deployment you will live with.

Recording is a separate question with a separate answer. A live view and a retention system solve different problems, and a module that displays streams is not a substitute for an NVR or VMS. CVI-RTSP displays live streams and does not record, store, or retain footage, so existing recording infrastructure stays where it is.

Common questions

Can I just put an rtsp:// link on a Perspective view?

No. Mainstream browsers, desktop and mobile alike, do not implement RTSP, so no video will play. The stream has to be republished in a browser-deliverable format such as HLS before any web page can display it.

Why is there a delay on the camera image?

HTTP-based streaming formats such as HLS deliver video in segments, and the player buffers before playback. With conventional segment durations that buffer is measured in seconds. CVI-RTSP typically lands in the 3 to 10 second range depending on cameras, network and gateway hardware.

Does viewing cameras this way replace an NVR?

No. Live viewing and recording are different jobs. CVI-RTSP displays live streams only and does not record, store or retain footage, so an existing NVR or VMS stays in place for retention.