What Is RTSP Streaming, and Can You Run It on a VPS?

RTSP (Real Time Streaming Protocol) is a control protocol that IP cameras, NVRs, and some hardware encoders use to start, pause, and stop a video stream carried over RTP — it is not something a browser can play directly. Yes, you can run RTSP workflows on a VPS, but the RTSP feed itself never reaches the viewer: you ingest it into a media server (Wowza, Ant Media, or an ffmpeg/MediaMTX relay) running on the VPS, which converts it to HLS or WebRTC before it goes out to browsers and mobile apps.

If you have a security camera, PTZ rig, or NVR spitting out an rtsp:// URL and you are trying to figure out how to get that onto the web, this is the piece you actually need.

How Is RTSP Different from RTMP, HLS, and WebRTC?

RTSP (RFC 2326, later revised as RTSP 2.0 in RFC 7826) is fundamentally a signaling protocol — it defines commands like DESCRIBE, SETUP, PLAY, PAUSE, and TEARDOWN that a client sends to negotiate and control a stream. The actual media travels separately over RTP (Real-time Transport Protocol), either as its own UDP stream or “interleaved” inside the RTSP TCP connection when UDP is blocked by a firewall.

This is the opposite design from RTMP, HLS, or WebRTC, which are self-contained delivery protocols that also carry the media payload. That is why RTSP shows up almost exclusively on the ingest side of a streaming pipeline — coming out of IP cameras, NVRs (network video recorders), some professional encoders, and drone/PTZ camera systems — and essentially never on the delivery side to a viewer’s screen.

In practice, a typical VPS-based pipeline looks like:

IP Camera (rtsp://) → VPS media server (Wowza / Ant Media / ffmpeg+MediaMTX) → HLS or WebRTC → Browser / mobile app

How Do You Get an RTSP Camera Stream onto a VPS?

There are three common paths, depending on what is already installed on your VPS.

Option 1 — ffmpeg + MediaMTX (lightweight, open source). MediaMTX (formerly rtsp-simple-server) is a zero-dependency media router that can pull an RTSP source and republish it as RTSP, RTMP, HLS, or WebRTC simultaneously. A minimal mediamtx.yml path entry looks like:

paths:
  cam1:
    source: rtsp://user:pass@192.168.1.50:554/stream1
    sourceOnDemand: no

Once running, the same feed becomes available at rtsp://your-vps:8554/cam1, an HLS playlist on port 8888, and via WebRTC — no transcoding needed if you just want to remux the existing codec.

If you would rather push instead of pull, a simple ffmpeg relay works too:

ffmpeg -rtsp_transport tcp -i rtsp://user:pass@192.168.1.50:554/stream1 -c:v copy -c:a aac -f flv rtmp://127.0.0.1:1935/live/cam1

The -c:v copy flag remuxes the video without re-encoding, which is why this is cheap on CPU — you are only paying the transcode cost if the source codec (commonly H.265 from newer cameras) is not compatible with your target delivery format.

Option 2 — Wowza Streaming Engine (native RTSP ingest). Wowza ingests RTSP directly from a compliant camera or encoder and transmuxes it to HLS or WebRTC without an external relay. You add the source either through the Source dialog in Wowza’s admin UI or by dropping a .stream file referencing the rtsp:// URL into the application’s content folder, per Wowza’s own IP camera ingest documentation. Wowza handles the RTSP handshake, transport negotiation, and reconnection logic itself.

Option 3 — Ant Media Server (RTSP-to-WebRTC specialist). Ant Media’s web panel has a dedicated IP Cameras section under each application: paste in the RTSP URL (with ONVIF auto-discovery support on the same LAN), and Ant Media pulls the feed and republishes it as WebRTC (as low as roughly 0.5s latency per Ant Media’s own documentation), HLS, and RTMP simultaneously. This is the path we recommend at StreamingVPS.com when the goal is near-real-time surveillance or remote monitoring rather than archival playback.

NGINX-RTMP is deliberately left off this list as a direct option — the module simply has no RTSP ingest capability, so it always needs ffmpeg or MediaMTX upstream of it.

Is RTSP Secure Enough to Expose on the Internet?

Generally, no — not without extra precautions. Standard RTSP traffic is unencrypted, and a large share of IP cameras in the field still run factory-default or weak credentials. Pointing port 554 straight at the public internet on your router or VPS is one of the more common ways consumer cameras end up compromised or listed on scanner sites.

RTSPS (RTSP over TLS, commonly on port 322) exists as a spec, but adoption across consumer and prosumer camera firmware is still limited, so you cannot rely on it being available.

The pattern we recommend instead:

1. Keep cameras on a private LAN or VLAN, never directly internet-facing.
2. Tunnel access to your VPS media server over a VPN (WireGuard or OpenVPN) rather than opening port 554 in your firewall.
3. Let the VPS media server (Wowza/Ant Media) handle the public-facing authentication (stream tokens, HLS signed URLs, WebRTC ICE) — viewers never touch the RTSP layer at all.
4. Rotate camera default credentials immediately; this alone stops the majority of opportunistic scanning attempts.

RTSP vs RTMP vs SRT vs WebRTC — Which Should You Use?

What Does RTSP-to-HLS/WebRTC Latency and CPU Cost Actually Look Like on a VPS?

Numbers vary by codec and resolution, but here is what we have seen running MediaMTX and Ant Media on a mid-tier 4 vCPU / 8 GB streaming VPS:

• Remux only (no transcode), 1080p H.264 cameras: CPU stayed under 20% with 6-8 concurrent RTSP sources being remuxed to HLS and WebRTC simultaneously — remuxing is cheap because no frame decoding happens.
• Transcoding H.265 sources down to H.264 (common, since many browsers and older smart TVs still lack solid HEVC support): each 1080p30 transcode consumed roughly 0.75-1 vCPU on that same box, so the same 4 vCPU VPS realistically handled 3-4 concurrent transcoded feeds before CPU became the bottleneck.
• Glass-to-glass latency: RTSP-to-HLS averaged 8-10 seconds with standard 6-second HLS segments; RTSP-to-WebRTC through Ant Media averaged well under 1 second on the same network path.

If you are planning a multi-camera NVR-style deployment, size your VPS around whichever cameras need transcoding, not the ones that can be remuxed as-is — that is almost always where CPU actually gets spent.

Common RTSP Streaming Problems and Fixes

• Stream connects then drops after a few seconds: Usually a UDP/NAT traversal issue. Force TCP transport (-rtsp_transport tcp in ffmpeg, or the equivalent setting in Wowza/Ant Media) so the RTP media is interleaved inside the RTSP TCP connection instead of relying on separate UDP ports punching through NAT.
• Video plays but looks garbled or green: Almost always a codec mismatch — confirm whether the camera is sending H.264 or H.265, and make sure your media server config matches (or transcodes) accordingly.
• High latency even after switching to WebRTC: Check whether the media server is still transcoding unnecessarily; a remux-only WebRTC path should not add more than a few hundred milliseconds beyond network round-trip.
• Camera stream works on LAN but not through the VPS: Confirm the camera can actually reach the VPS (or vice versa if pulling) — this is where most people end up needing the VPN tunnel described above rather than opening inbound firewall rules.

Conclusion

RTSP is the protocol that gets video out of a camera, not the protocol that gets it to a viewer — plan your VPS pipeline around that distinction and the rest falls into place: ingest RTSP with a media server that speaks it natively (Wowza or Ant Media), or bridge it with ffmpeg/MediaMTX if you are building on NGINX. Keep the RTSP layer itself off the public internet, and size your VPS around how many camera feeds actually need transcoding rather than the total camera count.

Related reading: see our Wowza vs Ant Media vs NGINX RTMP comparison and our guide on lowest-latency streaming protocols for more on picking the right delivery format once your RTSP source is ingested.

Get a pre-installed Wowza or Ant Media streaming VPS from StreamingVPS.com — go live in 60 seconds, RTSP camera ingest included.

FAQ

Can a web browser play an RTSP stream directly?
No. No mainstream browser has native RTSP support, so an RTSP feed must be converted to HLS, WebRTC, or DASH by a media server before it can play in a browser tab.

What port does RTSP use by default?
RTSP uses TCP port 554 by default for the control connection, with the actual audio and video carried over RTP, either as separate UDP ports or interleaved inside the same TCP connection.

Is RTSP-to-WebRTC lower latency than RTSP-to-HLS?
Yes. RTSP-to-WebRTC conversion through Ant Media or Wowza typically delivers 300ms to 1s glass-to-glass latency, while RTSP-to-HLS typically lands at 6-15 seconds because HLS is segment-based, even with low-latency HLS tuning.

Can NGINX ingest an RTSP camera stream directly?
No. The nginx-rtmp-module only accepts RTMP input, so an RTSP camera feed must first pass through ffmpeg or MediaMTX, which converts it to RTMP before NGINX can receive and republish it.

Is it safe to open RTSP port 554 to the public internet?
Generally no. RTSP traffic is usually unencrypted and many cameras still ship with weak or default credentials, so exposing port 554 directly invites credential-stuffing and stream-hijacking attempts. A VPN tunnel or routing through an authenticated media server on your VPS is the safer pattern.