What is RTSP? A plain English guide to the Real Time Streaming Protocol: how IP cameras use it, URLs and ports, RTSP vs RTMP, security and browser viewing.
RTSP, the Real Time Streaming Protocol, is the language most IP security cameras use to share live video. It was standardised by the IETF in RFC 2326.
Think of RTSP as a remote control. It tells a camera to start sending video, pause or stop. The video itself travels alongside it on a partner protocol called RTP. That split between control and delivery is what makes RTSP fast and flexible.
If you run security cameras, RTSP is almost certainly working in your building right now. This guide explains how it works, how cameras use it, where it falls short and how a modern video platform turns it into instant browser viewing and AI alerts.
RTSP follows a simple request and response pattern between a client, such as a recorder or video platform, and a server, such as a camera.
The client sends short commands, much like pressing buttons on a remote. DESCRIBE asks what video is available. SETUP agrees how it will be sent. PLAY starts it. PAUSE stops it for now. TEARDOWN ends the session and frees the camera's resources.
Once PLAY is sent, the video and audio flow over RTP. RTSP stays quietly in the background, ready for the next command.
Every RTSP stream has an address that looks a little like a web link: rtsp://[host]:[port]/[path]. For example, rtsp://camera.example.com:554/live/stream1.
The host is the camera's address on your network. The port is usually 554, the default set in RFC 2326. The path names the specific stream on that camera. Many cameras also accept a username and password in the address, which is why protecting these URLs matters.
A typical camera address looks like rtsp://username:password@192.168.1.100:554/stream1. The exact path differs by manufacturer, and finding it by trial and error wastes hours.
A good video platform removes that guesswork. It discovers cameras over ONVIF, the industry standard for camera interoperability, and finds the right stream addresses automatically.
Most IP cameras offer two RTSP streams. The main stream carries full resolution video, often 4K or 1080p. The sub stream carries a lighter, lower resolution version.
The main stream is for recording and investigation, where every detail counts. The sub stream is for live walls where dozens of small tiles share the screen. Using both keeps bandwidth under control without sacrificing evidence quality.
Picking the wrong stream for the job is one of the most common setup mistakes. Visylix avoids it by choosing the main or sub stream for each tile automatically, based on its size and the network.
Both protocols move live video, but they were built for different jobs. RTSP is a remote control that works with RTP to carry the video. RTMP bundles control and video into one connection.
RTSP grew up in security cameras and video recorders, where operators need to pull video from many devices and control playback. RTMP grew up in live broadcasting, where an encoder pushes one stream up to a streaming server.
In short, RTSP is how cameras share video with your security system. RTMP is how broadcasters push video to a platform. A modern video platform should accept both, and Visylix does.
RTSP fits security naturally. Its commands map directly onto what security systems need: connect to a camera, pull live video, record it and play it back.
It is also universal. Almost every IP camera maker, from budget brands to enterprise lines, supports RTSP. That means you can mix brands freely and avoid being locked into one supplier's cameras.
RTSP is reliable inside a network, but it was designed decades ago. Used on its own at scale, it creates real friction.
Large estates. Every camera needs its own connection, and running hundreds or thousands of them reliably takes a platform built for that volume.
Firewalls. RTSP sends control on one port and video on others that change from session to session. Firewalls often block those video channels, and streams fail before they reach the viewer. Switching to TCP helps, at some cost to speed.
Browsers. No modern browser plays RTSP. To watch cameras in a browser, video must be converted on a server to WebRTC or HLS.
Security. Basic RTSP sign in is weak and often unencrypted, and many cameras still ship with default passwords. Unhardened cameras are a real risk.
Newer formats. Older RTSP software can struggle with newer compression formats such as H.265. Modern platforms handle H.264 and H.265 side by side.
RTSP is best understood as the first link in a chain. It brings video from the camera to your server. Other protocols take it from there.
RTSP and RTP: camera to server. RTSP sets up the session and RTP carries the video. This is the backbone of almost every security system.
HLS: server to browser, with delay. HLS cuts video into short files that any browser can play, but it runs several seconds behind live. It suits playback and large audiences.
WebRTC: server to browser, live. WebRTC delivers video to the browser in under a second. It is the right choice for live monitoring and responding to alerts.
SRT: remote sites. SRT (Secure Reliable Transport) moves video reliably over unpredictable public networks, which makes it ideal for linking remote sites to a central control room.
Put together, they form a complete pipeline: RTSP from the camera, SRT for remote links, WebRTC for live operators and HLS for playback and wide audiences.
Visylix is an automated AI video surveillance platform from Aptibit Technologies, built around a native streaming engine designed for large camera estates. It connects to any RTSP or ONVIF camera, records it, watches it with AI and delivers it live to any browser.
Sub second live view. Visylix converts every camera to WebRTC for sub second live view, down to under 200 ms, with nothing to install at the desk. Where a network blocks WebRTC, tiles fall back to HLS or HTTP-TS automatically.
Any camera, any brand. Because RTSP is universal, Visylix works with cameras from any manufacturer, with ONVIF device packs for the top five brands. It can even read recordings directly from existing Hikvision, Dahua, Uniview, I8H, Bosch and Panasonic NVRs.
AI on every live feed. Visylix offers 22 AI analytics built in house, applied to live camera feeds: intrusion, line crossing, weapon detection, fire and smoke, PPE, number plate recognition, face recognition, crowd detection, falls and more. Each camera learns its own normal, and false alarm feedback tightens thresholds automatically.
From alert to action. Sudarshan rules decide which events matter and act: an alarm in the operator console, a signed webhook, an MQTT or SIEM event, or a talkdown through the camera speaker. The Radha AI copilot lets operators search and investigate in plain words.
Everything on premise. Every frame, AI result and record stays on your own hardware, on premise, at the edge or fully air gapped. Visylix ships as a Docker image, and Starter and Pro include unlimited cameras on the VMS licence from ₹4,999 or $49 per month, with AI added per camera per month.
Give every camera a fixed IP address. A camera that changes address breaks its RTSP URL without warning.
Update firmware before you go live. Many connection problems, and many security holes, are fixed in newer firmware.
Use consistent naming. Clear camera names and locations make large estates far easier to run.
Configure both streams. Set a full quality main stream for recording and a lighter sub stream for live walls.
Keep port 554 open between your cameras and your video platform, and close everything else. Put cameras on their own network segment so they are never directly reachable from the internet or from office computers.
Plan bandwidth for every camera, especially high resolution ones, and allow headroom for peaks such as busy scenes at night.
Change every default password and use strong, unique credentials. Use RTSPS where cameras support it, so video is encrypted on the wire. Allow camera access only from your video platform, and disable unused services on each camera.
Then protect the platform itself. Visylix supports Active Directory, LDAP and passkey sign in, 46 permissions across 4 roles, and a tamper evident audit trail of who watched and exported what.
Record continuously where risk is high and on events where storage is tight. Record the main stream for evidence quality.
Plan for the moment footage leaves your system. Visylix can lock evidence, seal it with SHA-256 and export it as a self contained player that opens offline, so investigators and courts can check the footage is untouched. Faces, plates and custom zones can be redacted on export.
RTSP is the remote control behind almost every IP camera. It sets up live video sessions, while RTP carries the video itself. Port 554 is the default.
It is universal and reliable inside a network, but on its own it struggles with large estates, firewalls, browsers and security.
A modern platform keeps RTSP where it is strong, between camera and server, and delivers sub second WebRTC to operators, AI on every feed and evidence anyone can verify. That is exactly what Visylix is built to do.
RTSP uses port 554 by default, over TCP or UDP. RTSPS, the encrypted version of RTSP, commonly uses port 322. Many cameras let you change the port in their settings.
No. RTSP is the control channel: it starts, pauses and stops a video session. RTP (Real Time Transport Protocol) carries the actual video and audio. They work as a pair.
It can, but it was built for local networks. Firewalls and routers often block the separate channels RTSP uses for video. The safer approach is to keep RTSP inside your network and let your video platform deliver video to remote viewers securely over WebRTC or HLS.
For a test, open source tools such as FFmpeg or GStreamer can publish an rtsp:// address on port 554. For a real security estate, a video management platform does this for you: it connects to every camera, records, runs AI and delivers live video to browsers without manual server work.
VLC for iOS and Android is the most dependable choice for viewing a single RTSP stream. For day to day security work, a browser based video platform is far simpler, since phones and tablets play WebRTC and HLS natively.
Tools such as FFmpeg can repackage an RTSP feed into HLS or DASH, which browsers play natively. A video platform such as Visylix does this automatically for every camera, and also offers sub second WebRTC for live view.
It depends on camera count, resolution and whether you record and run AI on the same machine. Plan for enough processor cores, memory, network capacity and fast storage for your estate. Visylix sizes hardware with you for your actual cameras and retention.
Start with the basics: check the camera address, username and password in the RTSP URL, and confirm port 554 is open. If video stutters or drops, switch the transport from UDP to TCP. Give every camera a fixed IP address so its URL never changes.
RTSP is built for fast, direct links between cameras and servers inside a network. HLS and DASH cut video into short files for delivery over the web, which reaches any browser but adds seconds of delay. For live browser viewing without that delay, WebRTC is the modern choice.
Browsers cannot play RTSP directly, so the stream must be converted on a server to WebRTC or HLS. Visylix does this for every camera, with sub second live view over WebRTC and automatic fallback to HLS where a network blocks it.
Change default passwords, use strong unique credentials, use RTSPS where cameras support it, keep cameras on a separate network segment, allow access only from your video platform, and keep camera firmware up to date.
Very much so. Almost every IP camera still speaks RTSP, and it remains the standard way for a video platform to pull live video from a camera. What has changed is how video reaches the viewer, which is now WebRTC or HLS in the browser.
RTSP was developed by RealNetworks, Netscape and Columbia University, and standardised by the IETF (Internet Engineering Task Force) as RFC 2326 in 1998. An updated version, RTSP 2.0, followed later.