Vidéosurveillance (serveur RTSP)¶
Important
Version bêta 2.1. Ce qui est décrit ici n’existe que dans la version bêta 2.1 : elle s’installe depuis le dépôt bêta et uniquement avec une licence ; la version stable 2.0.2 et la version de démonstration ne l’ont pas. La version bêta est fournie sans garantie, et l’assistance est assurée dans la mesure du possible (Programme de test bêta).
Depuis la version 2.1.0.485, un nœud peut diffuser ses flux SPTS en RTSP vers des systèmes de gestion vidéo (VMS) et des lecteurs, par exemple VLC et ffmpeg. Depuis la version 2.1.0.493, l”archive du flux se lit aussi à la même adresse. Le serveur se configure dans l’écran « Vidéosurveillance » (Vidéosurveillance) ; la version de démonstration ne l’a pas.
Direct¶
Par défaut, le serveur RTSP est désactivé : tant qu’il l’est, le nœud n’ouvre pas le port RTSP. Une fois activé, le serveur diffuse chaque flux SPTS du nœud ; il n’y a ni interrupteur ni liste d’accès par flux. Les flux MPTS ne sont pas diffusés.
Adresse du flux:
rtsp://<hôte>:<port>/<flux>
Ici, <flux> est le nom OTT du flux (le même que dans ses adresses HLS, même si l’OTT est désactivé) ou son numéro. Le port par défaut est 554.
La vidéo H.264 ou H.265 avec un son AAC ou AC-3 est transmise en flux RTP distincts ; le son dans d’autres codecs n’est pas transmis.
Un flux dont la vidéo n’est ni H.264 ni H.265 (par exemple MPEG-2), ou qui n’a pas de vidéo, est transmis en entier en MPEG-TS sur RTP.
Le RTP passe dans la connexion TCP du RTSP ou, depuis la version 2.1.0.494, en UDP. En UDP, la vidéo n’est envoyée qu’à l’adresse du client lui-même ; le multicast n’est pas proposé. Un client derrière un NAT a besoin du TCP : la plupart des lecteurs y passent d’eux-mêmes. En UDP, l’archive est toujours envoyée en temps réel. Avant la version 2.1.0.494, le serveur refusait une demande en UDP, et VLC et ffmpeg passaient d’eux-mêmes en TCP.
La lecture commence à l’image clé suivante.
Note
ffmpeg comme client d’enregistrement (-c copy) ne peut pas horodater la première image d’une source H.264 avec des images B. Un lecteur affiche et enregistre une telle source.
RTSPS (RTSP sur TLS)¶
Depuis la version 2.1.0.494, le serveur accepte aussi le RTSPS — du RTSP dans une connexion TLS chiffrée, sur un port distinct:
rtsps://<hôte>:<port RTSPS>/<flux>
Le RTSPS s’active sur l’écran « Vidéosurveillance » avec l’interrupteur « RTSPS (RTSP sur TLS) » ; le « Port RTSPS » s’y trouve aussi, 322 par défaut (Vidéosurveillance). Dans les paramètres du nœud, ce sont les clés rtsps-enable et rtsps-port de la section surveillance.
Le serveur a besoin d’un certificat et d’une clé au format PEM : les fichiers surveillance.crt et surveillance.key dans le répertoire /opt/pss/config/cert. Sans eux, le RTSPS ne démarre pas : le nœud signale l’erreur dans l’état du serveur de l’API HTTP (/data/surveillance) et réessaie toutes les 10 s.
En RTSPS, la vidéo passe toujours dans la connexion chiffrée : le serveur refuse une demande en UDP, et le client passe en TCP. Rien n’est transmis en clair.
Comptes d’annuaire¶
Depuis la version 2.1.0.497, des comptes d’un annuaire LDAP ou d’Active Directory peuvent aussi se connecter au serveur RTSP. Pour cela, sur l’écran « Vidéosurveillance », choisissez dans « Authentification » « Digest pour les identifiants, Basic pour l’annuaire (RTSPS uniquement) » (la clé rtsp-auth avec la valeur 3) et activez le RTSPS (RTSPS (RTSP sur TLS)). Les comptes d’annuaire se connectent uniquement en RTSPS et en Basic, à l’intérieur de TLS. En RTSP ordinaire, Basic n’est ni proposé ni accepté : seuls les identifiants RTSP locaux s’y connectent, en Digest. Depuis la version 2.1.1.502, en RTSPS dans ce mode, les identifiants locaux se connectent eux aussi en Basic (à l’intérieur de TLS) ; à un client qui ne sait faire que Digest, il reste le RTSP ordinaire avec un identifiant local. Quels groupes ont droit au RTSP et avec combien de sessions simultanées se définit dans « Accès RTSP par groupe » (Spectateurs et RTSP par l’annuaire). Depuis la version 2.1.0.499, les systèmes de vidéosurveillance et les lecteurs basés sur live555 (VLC, openRTSP et de nombreux VMS) se connectent eux aussi en RTSPS avec un compte d’annuaire.
Lecture de l’archive¶
Depuis la version 2.1.0.493, l’archive du flux se lit à la même adresse RTSP que le direct. Il faut un flux qui enregistre une archive, c’est-à-dire avec un « Stockage DVR » défini (DVR : archive du flux) ; sans stockage, pas de lecture de l’archive.
Les systèmes de gestion vidéo demandent un intervalle de temps en UTC (selon les règles ONVIF) :
chaque image arrive avec son heure d’enregistrement ;
l’archive est envoyée en temps réel ou, si le client le demande, aussi vite que le réseau le permet ;
la pause, la reprise et le saut vers un autre moment fonctionnent.
Les lecteurs (VLC, ffmpeg) ouvrent l’adresse avec des paramètres:
rtsp://<hôte>:<port>/<flux>?t=<heure Unix>[&d=<secondes>]
t est le début, en secondes Unix (UTC). Le curseur de navigation fonctionne. Avec d, la lecture s’arrête au bout du nombre de secondes indiqué.
Début. La lecture commence à une image clé au moment demandé ou avant — jusqu’à un segment d’archive plus tôt. Si le moment demandé précède le début de l’archive, la lecture commence au début de l’archive.
Fin.
Si la fin de l’intervalle (ou
d) est indiquée, la lecture s’y arrête.Si aucune fin n’est indiquée, la lecture passe au direct une fois qu’elle a rattrapé l’enregistrement.
Si l’enregistrement s’est arrêté (par exemple, la caméra ne fonctionne pas), la lecture se termine sur la dernière image enregistrée.
Caméra arrêtée. Un flux qui ne reçoit pas de données peut quand même être ouvert, et son archive lue.
Limites :
Vitesse normale uniquement : pas de lecture accélérée ni ralentie.
Un flux transmis en entier en MPEG-TS (sans vidéo H.264 ou H.265) n’est disponible qu’en direct.
Les sessions ouvertes sont visibles dans l’écran « Vidéosurveillance » (Vidéosurveillance) et dans l’API HTTP (/data/surveillance, Pilotage via l’API HTTP) : pour chacune, on voit s’il s’agit du direct ou de l’archive et, pour l’archive, le moment de la dernière image envoyée.
