RTSP is the protocol that carries the actual video from an IP camera to your NVR, and ONVIF is the vendor-neutral standard that lets any compliant recorder discover the camera and find that video stream automatically. Put simply: RTSP is the pipe, ONVIF is the handshake. A camera that speaks both will work with Frigate, Blue Iris, or Synology; a camera that speaks only its own app will lock you out of a real self-hosted setup.
I learned this distinction the expensive way. My first two “smart” cameras only spoke to their manufacturer’s cloud app — no documented RTSP URL, no ONVIF, no way to pull a stream into anything I controlled. They became doorstops the day I stood up a real NVR. Now I read the spec sheet for one line before I buy anything: does it publish an RTSP path and pass ONVIF? If not, it doesn’t come home. This guide is the thing I wish I’d understood before that first purchase.
What Is RTSP and What Does It Actually Do?
RTSP — the Real Time Streaming Protocol, defined in IETF RFC 2326 — is a control protocol that establishes and manages a media stream. It doesn’t carry the video bytes itself; it’s the remote control that tells the camera “start sending,” “pause,” and “tear down,” while the actual H.264 or H.265 video usually travels over RTP alongside it. When your NVR “connects to the camera,” it’s opening an RTSP session and then receiving the RTP media that session negotiates.
In practice you interact with RTSP through a URL. It looks like rtsp://username:[email protected]:554/stream1 — protocol, credentials, the camera’s IP, port 554 (the RTSP default), and a path that identifies which stream you want. Point VLC at that URL and the live feed plays; point Frigate at it and the camera is now a recording source. The first time I got a stream playing in VLC straight from the URL, with no vendor app anywhere in the chain, was the moment self-hosting clicked for me. That URL is the camera, laid bare.
The port matters for your firewall rules. Cameras stream RTSP on 554 by default, and your NVR needs to reach that port on the camera VLAN — one of the few flows you explicitly allow across the segment boundary described in the home camera network guide. Everything else from the camera gets dropped.
Why Do Cameras Have Two RTSP Streams?
Almost every decent IP camera publishes two RTSP streams from the same sensor: a high-resolution “main” stream for recording, and a low-resolution “sub” stream for cheap real-time analysis. The main stream might be 4 MP at 4 Mbit/s; the sub-stream might be 640×480 at a few hundred Kbit/s. Using the right stream for the right job is the single biggest performance lever in an NVR build.
Here’s why it matters. Motion detection and object detection run on every single frame, continuously. If your NVR decodes and analyzes the full 4 MP main stream, it burns enormous CPU for no benefit — a person-shaped blob is just as detectable at 640×480. So you point the detect role at the sub-stream and the record role at the main stream. In my Frigate config that one split is the difference between a Coral TPU calmly handling eight cameras and a CPU pegged at 100% on four. It also keeps the heavy main-stream traffic flowing only when there’s something worth recording.
The sub-stream URL is usually a sibling path — /stream1 and /stream2, or /h264Preview_01_main and /h264Preview_01_sub, depending on the manufacturer. This is exactly why documented RTSP paths matter: you need to know both URLs, and a camera that hides them behind an app is a camera you’ll fight forever.
What Is ONVIF and How Is It Different From RTSP?
ONVIF is an industry standard that defines a common interface for IP cameras and NVRs to talk to each other — discovery, configuration, event handling, and PTZ control — regardless of manufacturer. Where RTSP just moves the video, ONVIF is the layer that lets a recorder find the camera on the network, ask it for its RTSP stream URLs, subscribe to its motion events, and pan a PTZ head, all through one vendor-neutral API.
The value is interoperability. Before ONVIF, every camera and NVR pairing was a proprietary guessing game. Now, a compliant NVR can auto-discover a compliant camera and pull its configuration without you hand-typing anything. ONVIF organizes this into Profiles — Profile S for streaming, Profile T for advanced streaming with H.265, Profile G for recording and storage. When a spec sheet says “ONVIF Profile S/T,” it’s telling you the camera will hand its stream URLs to any recorder that asks. The ONVIF organization publishes the full profile definitions, and it’s worth a glance before buying.
Do You Even Need ONVIF If You Have the RTSP URL?
Not strictly — if you already know the RTSP URLs, you can point an NVR straight at them and skip ONVIF discovery entirely. That’s how I actually run mine. My cameras get DHCP reservations, I know each one’s IP and stream path, and Frigate connects by hardcoded RTSP URL. ONVIF’s auto-discovery is a convenience I don’t need once the addresses are pinned.
ONVIF earns its keep in two places even in a static setup: event subscription and PTZ. If you want the camera’s own motion or line-crossing events fed to the NVR (instead of the NVR computing motion itself), that comes over ONVIF. And any pan-tilt-zoom control goes through ONVIF’s PTZ service. For a fleet of fixed bullet cameras doing detection in Frigate, I ignore ONVIF entirely and just use RTSP. For a PTZ camera I want to auto-track, ONVIF becomes essential. Know which camp you’re in before you buy — it changes what “ONVIF compliant” needs to mean for you.
How Do RTSP and Codecs Fit Together?
RTSP carries whatever codec the camera encodes in — overwhelmingly H.264 or H.265 (HEVC) today. The codec is independent of the streaming protocol: RTSP is the transport, the codec is the compression. But the codec choice has huge downstream effects, because H.265 delivers roughly the same visual quality as H.264 at about half the bitrate, which directly halves your storage and LAN bandwidth.
The catch is decoder support. Some older NVR software and some browsers struggle to decode H.265, and hardware-accelerated H.265 decode isn’t universal on every mini-PC. Frigate handles it fine with the right hardware acceleration on the homelab NVR build I run, and it’s what I run on all my cameras for the storage savings — but I confirmed my NVR’s hardware could decode HEVC before committing. If you’re on marginal hardware, H.264 is the safe, universally-decodable fallback. The bitrate and codec math feeds directly into how much disk you need, which I work through in the storage sizing section of the main guide.
Should RTSP Run Over TCP or UDP?
RTSP can carry its media over either TCP or UDP, and for a home NVR on a wired LAN, TCP is the right default. UDP is lower-latency and lighter, but it drops packets silently under load, which shows up as smearing, tearing, or green artifact blocks in a recorded clip — exactly when you least want them. TCP retransmits lost packets, so the recording stays clean at the cost of a little latency you won’t notice on a recorded stream.
I run every camera over RTSP-interleaved TCP in Frigate. On a gigabit wired camera VLAN the latency penalty is negligible, and I’ve never had the packet-loss artifacts that plagued my early UDP experiments over a congested switch. The one place UDP genuinely wins is ultra-low-latency live viewing of a PTZ camera you’re actively steering, where a fraction of a second matters — but for recording and detection, clean beats fast every time. If your NVR lets you pick the transport per camera, set it to TCP and forget it.
The Configuration Mistake That Cost Me an Evening
I once spent an entire evening convinced a new camera was broken because my NVR couldn’t pull its stream, even though the camera pinged fine and its own web UI worked. The camera was on the isolated CAMERA VLAN, the NVR was on the LAN, and I’d allowed the NVR to reach the camera — but I’d allowed the wrong port. I’d opened HTTP (80) for the web UI in my head and forgotten the stream itself rides RTSP on 554. The web page loaded across the boundary; the video never could.
The lesson: when a camera is reachable but streamless across a VLAN, check the RTSP port before you check anything else. The web UI and the RTSP stream are two different ports, and a firewall rule that allows one doesn’t allow the other. This is exactly the kind of trap that lives in the intersection of the streaming protocols and the network segmentation that isolates the cameras — the protocol knowledge and the firewall knowledge have to line up or nothing streams.
What to Look For on a Camera Spec Sheet
Before buying, I check three lines: a documented RTSP URL format, ONVIF Profile S or T compliance, and H.265 support. Those three together mean the camera will drop into any real NVR, hand over both its streams, and sip storage — the same checklist I used to pick the PoE cameras I actually run. Miss any of them and you’re either locked into a vendor app, hunting undocumented URLs, or paying double in disk. A managed PoE switch and a proper VLAN are the network side of this — covered in managed switch setup — but the camera has to speak the standards for any of it to matter.
Further Reading
- Home Camera Network & NVR: The Self-Hosted Guide — the full architecture this streaming layer plugs into.
- Network Segmentation for the Home Lab — the VLAN thinking behind isolating cameras.
- Managed Switch Setup — the tagged/untagged port discipline cameras ride on.
What is the difference between RTSP and ONVIF?
RTSP is the streaming protocol that carries the actual video from the camera to the recorder. ONVIF is a vendor-neutral standard that lets a recorder discover the camera, retrieve its RTSP stream URLs, subscribe to events, and control PTZ. RTSP moves the video; ONVIF is the handshake that finds and configures it.
Do I need ONVIF if I already have the RTSP URL?
No. If you know the camera’s RTSP URLs you can point the NVR directly at them and skip ONVIF discovery entirely. ONVIF still matters for event subscription and PTZ control, but for fixed cameras with known stream URLs, RTSP alone is enough.
Why does my IP camera have two RTSP streams?
Cameras publish a high-resolution main stream for recording and a low-resolution sub-stream for real-time analysis. Pointing motion and object detection at the low-res sub-stream instead of the main stream dramatically reduces CPU and bandwidth while recording still captures full quality.
What port does RTSP use?
RTSP uses TCP port 554 by default. When cameras are on an isolated VLAN, the NVR must be explicitly allowed to reach port 554 on the cameras. Note that the camera web interface uses a separate port, so allowing HTTP does not allow the video stream.
What I’d do starting today: pick one camera, find its RTSP main and sub URLs, and play both in VLC before you buy a second. If the URLs are documented and the streams play, you have a camera that will serve you for a decade. If you can’t get a stream out without the app, send it back.