---
title: Surveillance (RTSP server)
url: https://doc2.pstreamer.tv/en/manual/streamer/surveillance.html
lang: en
product: Perfect Streamer
version: 2.0.2.423
---

# Surveillance (RTSP server)

> **Important**
>
> **Beta version 2.1.** What is described here exists only in beta version 2.1: it is installed from the beta repository and only with a licence; the stable version 2.0.2 and the demo edition do not have it. The beta version comes without warranty, and support is best effort ([Beta testing programme](../extras/beta.md#extras-beta)).

Since version 2.1.0.485 a node can serve its SPTS streams over RTSP to video management systems (VMS) and players such as VLC and ffmpeg. Since version 2.1.0.493 the stream’s archive plays at the same address too. The server is set up on the “Surveillance” screen ([Surveillance](../webui/administration.md#webui-surveillance)); the demo edition does not have it.

## Live

The RTSP server is off by default: while it is off, the node does not open the RTSP port. When on, the server serves every SPTS stream of the node; there is no per-stream switch or access list. MPTS streams are not served.

Stream address:

```
rtsp://<host>:<port>/<stream>
```

Here `<stream>` is the OTT name of the stream (the same as in its HLS addresses, even if OTT is off) or its number. The default port is 554.

- H.264 or H.265 video with AAC or AC-3 audio is sent as separate RTP streams; audio in other codecs is not sent.
- A stream whose video is neither H.264 nor H.265 (for example, MPEG-2), or that has no video, is sent whole as MPEG-TS over RTP.
- RTP goes inside the RTSP TCP connection or, since version 2.1.0.494, over UDP. Over UDP video is sent only to the client’s own address; multicast is not offered. A client behind NAT needs TCP: most players switch to it by themselves. Archive over UDP always goes in real time. Before version 2.1.0.494 the server refused a UDP request, and VLC and ffmpeg switched to TCP by themselves.
- Playback starts at the next key frame.

> **Note**
>
> ffmpeg as a recording client (`-c copy`) cannot set a timestamp on the first frame of an H.264 source with B-frames. A player both shows and records such a source.

## RTSPS (RTSP over TLS)

Since version 2.1.0.494 the server also accepts RTSPS — RTSP in an encrypted TLS connection, on a separate port:

```
rtsps://<host>:<RTSPS port>/<stream>
```

RTSPS is turned on on the “Surveillance” screen with the “RTSPS (RTSP over TLS)” switch; the “RTSPS port” is there too, 322 by default ([Surveillance](../webui/administration.md#webui-surveillance)). In the node settings these are the `rtsps-enable` and `rtsps-port` keys of the `surveillance` section.

The server needs a certificate and a key in PEM format: the files `surveillance.crt` and `surveillance.key` in the `/opt/pss/config/cert` directory. Without them RTSPS does not start: the node reports the error in the server state in the HTTP API (`/data/surveillance`) and retries every 10 s.

Over RTSPS video always goes inside the encrypted connection: the server refuses a UDP request, and the client switches to TCP. Nothing is sent in clear text.

## Directory accounts

Since version 2.1.0.497, LDAP or Active Directory accounts can also connect to the RTSP server. For this, on the “Surveillance” screen choose “Authentication” — “Digest for logins, Basic for directory (RTSPS only)” (the `rtsp-auth` key with the value `3`) and turn RTSPS on (RTSPS (RTSP over TLS)). Directory accounts sign in over RTSPS only and with Basic, inside TLS. Over plain RTSP, Basic is neither offered nor accepted: only local RTSP logins sign in there, with Digest. Since version 2.1.1.502, over RTSPS in this mode local logins also sign in with Basic (inside TLS); a client that can do only Digest is left with plain RTSP and a local login. Which groups are allowed RTSP and how many sessions at the same time is set in “RTSP access by group” ([Viewers and RTSP through the directory](../webui/administration.md#webui-ldap-viewers)). Since version 2.1.0.499, surveillance systems and players based on live555 (VLC, openRTSP and many VMS) also sign in over RTSPS with a directory account.

## Archive playback

Since version 2.1.0.493 the stream’s archive plays at the same RTSP address as the live stream. The stream must write an archive, that is, have a “DVR storage” set ([DVR: the stream archive](ott_dvr.md#streamer-dvr)); without a storage there is no archive playback.

**Video management systems** request a time interval in UTC (by the ONVIF rules):

- every frame arrives with its own recording time;
- the archive is sent in real time or, if the client asks, as fast as the network allows;
- pause, resume and a jump to another moment work.

**Players** (VLC, ffmpeg) open the address with parameters:

```
rtsp://<host>:<port>/<stream>?t=<Unix time>[&d=<seconds>]
```

`t` is the start, in Unix seconds (UTC). The seek bar works. With `d` playback ends after the given number of seconds.

**Start.** Playback starts at a key frame at the requested moment or before it — up to one archive segment earlier. If the requested moment is before the start of the archive, playback starts at the start of the archive.

**End.**

- If the end of the interval (or `d`) is set, playback stops there.
- If no end is set, playback switches to live once it catches up with the recording.
- If the recording stopped (for example, the camera is down), playback ends at the last recorded frame.

**Stopped camera.** A stream with no data can still be opened, and its archive played.

Limits:

- Normal speed only: there is no fast or slow playback.
- A stream sent whole as MPEG-TS (without H.264 or H.265 video) is available live only.

Open sessions are shown on the “Surveillance” screen ([Surveillance](../webui/administration.md#webui-surveillance)) and in the HTTP API (`/data/surveillance`, [Managing the node over the HTTP API](../extras/api.md#extras-api)): for each one it shows whether it is live or archive, and for the archive, the moment of the last frame sent.
