Tutorial: RTSP-Adressen für IP-Kameras bauen und prüfen

Eine RTSP-Adresse bezeichnet einen Mediendienst und den gewünschten Stream. RTSP steuert die Sitzung; die Videodaten werden häufig in RTP-Paketen übertragen. Unterstützung, Pfade, Anmeldung und Transportmöglichkeiten hängen von Modell und Firmware ab. Eine erfolgreiche Verbindung ist der erste Prüfschritt, kein Nachweis einer zuverlässigen Aufzeichnung.

1. Den tatsächlichen Server bestimmen

Der Host kann Kamera, Rekorder, Protect-Konsole oder Restreamer sein. Entscheidend ist die Komponente, die diesen Stream bereitstellt. Ein Kamerakonto gilt nicht automatisch am Rekorder. Port 554 ist der übliche RTSP-Standardport; maßgeblich bleibt der konfigurierte Port.

Die folgende erfundene Adresse zeigt die Bestandteile. Zugangsdaten in der URL sind eine vom Client unterstützte Konvention, deren Kompatibilität geprüft werden muss. Getrennte Zugangsdatenfelder sind vorzuziehen, sofern vorhanden.

rtsp://viewer:Example%402026@192.0.2.10:554/Streaming/Channels/102
Schema | Nutzer:Passwort     | Host      | Port | Pfad

Weder Host noch Zugangsdaten oder Port sind bei allen Kameras identisch. Eine ausgeschriebene IPv6-Adresse benötigt eckige Klammern, etwa rtsp://[2001:db8::10]:554/stream. Eine Abfragezeichenfolge kann weitere Einstellungen auswählen. Die genaue Bedeutung ergibt sich aus der Gerätedokumentation.

2. Den Pfad aus Gerät oder Dokumentation übernehmen

Das sind Beispiele, keine universellen Adressen. Im Hikvision-Muster steht der Kanal vor der zweistelligen Stream-Kennung: Kanal 12 mit Stream 02 ergibt 1202. Ein Kanal bezeichnet nicht grundsätzlich ein physisches Objektiv. Der Axis-Parameter für die Auflösung fordert eine unterstützte Größe an und benennt nicht automatisch einen festen „Substream“.

Bei einem kompatiblen ONVIF-Mediendienst ermittelt GetProfiles die verfügbaren Medienprofile. GetStreamUri fordert eine URI für das gewählte Profil und den Transport an. Anmeldung, Erreichbarkeit und Clientkompatibilität bleiben zu prüfen. Eine zurückgegebene private Adresse ist nicht automatisch aus einem anderen Netz erreichbar.

Ubiquitis offizielle Portübersicht führt für Protect sowohl RTSPS auf 7441 als auch RTSP auf 7447 auf. Die frühere Behauptung einer grundsätzlichen Ablehnung von unverschlüsseltem RTSP war zu weitgehend. Die konfigurierte, unterstützte Exportadresse und Konsolenversion haben Vorrang vor geratenen URL-Umbauten.

3. Zugangsdaten kodieren, Kodierung nicht mit Verschlüsselung verwechseln

Reservierte Zeichen können die Zerlegung einer URL verändern. Nutzername und Passwort werden getrennt kodiert: @ → %40, / → %2F, # → %23, ? → %3F, % → %25 und Leerzeichen → %20. Ein Doppelpunkt als %3A vermeidet Mehrdeutigkeit; ein Doppelpunkt innerhalb der Nutzerinformation beendet dieses Feld aber nicht grundsätzlich. Bereits kodierte Werte dürfen nicht erneut kodiert werden.

Prozentkodierung ist umkehrbar und bietet keine Geheimhaltung. Digest-Anmeldung überträgt das Passwort selbst nicht im Klartext. Das verschlüsselt jedoch nicht das Video. Außerdem verwenden nicht alle Kameras Digest. Basic-Anmeldung ohne Transportschutz legt wiederherstellbare Zugangsdaten offen. RTSPS schützt die Steuerverbindung mit TLS; der Schutz der Medien hängt vom ausgehandelten Transport ab.

Ein eigenes Zuschauerkonto begrenzt Berechtigungen. URLs und Kennungen bleiben in Prozessargumenten, Protokollen und Konfigurationen vertraulich zu behandeln. Lokale Kodierung vermeidet die Übertragung echter Passwörter an einen Online-Kodierer.

4. Metadaten mit einer Zeitgrenze prüfen

Das Bash-Beispiel benötigt ffprobe und GNU timeout. Die URL wird ohne Terminalanzeige eingelesen. Anschließend fordert der Befehl TCP-Transport im Steuerkanal an und gibt die Metadaten des ersten Videostreams aus. Die Eingabe steht dadurch nicht als ausgeschriebener Befehl in der Shell-Historie. Das aufgelöste Argument kann trotzdem bei berechtigter Prozessabfrage oder in Fehlermeldungen sichtbar werden.

IFS= read -r -s -p 'RTSP URL: ' RTSP_URL
printf '\n'
timeout -k 2s 15s ffprobe -v error \
  -rtsp_transport tcp -timeout 5000000 \
  -select_streams v:0 \
  -show_entries stream=codec_name,width,height,avg_frame_rate \
  -of json "$RTSP_URL"
probe_status=$?
unset RTSP_URL
printf 'Exit status: %s\n' "$probe_status"

-timeout 5000000 begrenzt RTSP-Socket-Wartezeiten in der geprüften Version FFmpeg 7.1.5 auf fünf Sekunden. Der äußere Befehl setzt unabhängig davon eine Laufzeitgrenze von 15 Sekunden mit weiteren zwei Sekunden bis zum erzwungenen Ende. GNU timeout liefert bei Fristablauf gewöhnlich Rückgabewert 124. Eine gültige Kamera muss deshalb nicht innerhalb von zwei Sekunden antworten.

Codec und Bildgröße im JSON bestätigen brauchbare Metadaten, keine dauerhafte Paketlieferung oder erfolgreiche Dekodierung. Ein fehlender Videoeintrag ist kein bestandener Videotest. Danach prüfen ein Player und eine repräsentative Aufzeichnung tatsächliche Bilder, Bewegung, Tag/Nacht-Wechsel und Wiederverbindung.

TCP-Übertragung im Steuerkanal kann getrennte UDP-Medienports vermeiden. Falsche Pfade, ungeeignete Codecs, fehlende Berechtigungen oder Verbindungsverlust werden dadurch nicht behoben. Auch UDP kann passend sein; Paketverlust und Pufferung bestimmen den praktischen Latenzunterschied.

5. Erkennung und Aufzeichnung bewusst aufteilen

Frigate erlaubt einen Eingang mit detect und einen mit record. Der Ausschnitt zeigt die Rollen für einen bestätigten Pfad im Hikvision-Stil. Die vollständige Konfiguration benötigt zusätzlich passende Aufzeichnungseinstellungen und eine Prüfung mit der installierten Frigate-Version.

cameras:
  driveway:
    ffmpeg:
      inputs:
        - path: "rtsp://{FRIGATE_RTSP_USER}:{FRIGATE_RTSP_PASSWORD}@192.0.2.10:554/Streaming/Channels/102"
          input_args: preset-rtsp-generic
          roles: [detect]
        - path: "rtsp://{FRIGATE_RTSP_USER}:{FRIGATE_RTSP_PASSWORD}@192.0.2.10:554/Streaming/Channels/101"
          input_args: preset-rtsp-generic
          roles: [record]

Umgebungsvariablen werden nur in dokumentierten Konfigurationsfeldern ersetzt. Die Passwortvariable enthält hier den URL-kodierten Wert. Eine geschützte Umgebungsdatei reduziert versehentliches Weitergeben; Laufzeitwerte sind dadurch kein Geheimnisspeicher.

Ein kleinerer Erkennungsstream kann den Dekodieraufwand senken, aber entfernte Ziele zu klein darstellen. Bei gleichem Bildausschnitt verringert eine Breite von 640 statt 3840 Pixeln die lineare Pixeldichte auf ein Sechstel. Umfasst ein idealisiertes Ziel zunächst 172,8 Pixel, bleiben nach Skalierung 28,8 Pixel. Beschnitt, Perspektive und Kodierung können das praktische Ergebnis verändern. Daraus folgt keine Erkennungsgarantie.