Tutorial: RTSP-Adressen für IP-Kameras bauen und prüfen
Inhalt
Eine IP-Kamera liefert ihr Video über RTSP, und RTSP ist genormt. Die Adresse, die zum Video führt, ist es nicht. Jeder Hersteller hat sich einen eigenen Pfad ausgedacht, und eine Kamera, die auf dem falschen Pfad angesprochen wird, antwortet genauso wie auf ein falsches Passwort: gar nicht.
Sechs Teile bilden eine solche Adresse. Vier davon sehen auf jeder Kamera gleich aus, zwei müssen je Hersteller nachgeschlagen werden. Es folgt die Reihenfolge, in der sich die Teile am besten zusammensetzen lassen, und der eine Befehl, der klärt, ob das Ergebnis funktioniert – bevor es im Rekorder verschwindet, wo sich der Fehler hinter sechs anderen Einstellungen versteckt.
Die sechs Teile einer Stream-Adresse
Eine RTSP-Adresse ist gebaut wie eine Webadresse: Schema, Zugangsdaten, Host, Port, Pfad und auf manchen Kameras eine Abfragezeichenfolge, die die Stream-Nummer trägt.
rtsp://admin:Sommer%402026@192.168.1.64:554/Streaming/Channels/102
rtsp://admin:Sommer%402026@192.168.1.64:554/cam/realmonitor?channel=1&subtype=1
rtsps://192.168.1.1:7441/aBcD1234EfGh?enableSrtpDas Schema lautet rtsp und der Port 554, solange ihn niemand verschoben hat. Ubiquiti ist die Ausnahme, die im Gedächtnis bleiben sollte: UniFi Protect antwortet auf rtsps an Port 7441, lehnt einfaches RTSP ab und vergibt statt eines lesbaren Pfads eine undurchsichtige Kennung. Diese Kennung erscheint erst, nachdem RTSP für die einzelne Kamera in Protect eingeschaltet wurde.
Host meint die Kamera, niemals den Rekorder. Ein Rekorder kann einen Stream erneut ausliefern, dann aber unter eigener Adresse an eigenem Port – und ein Fehler auf dieser Ebene sieht aus wie eine defekte Kamera.
Warum der Pfad auf jeder Kamera anders heisst
Der Pfad trägt zwei Angaben, für die RTSP selbst kein Feld vorsieht: welches Objektiv und welcher seiner Streams. Fast jede Kamera bietet mindestens zwei – einen Hauptstream in voller Auflösung für die Aufzeichnung und einen Substream mit einem Viertel davon für Vorschau und Bewegungsanalyse.
| Hersteller | Hauptstream | Substream |
|---|---|---|
| Hikvision | /Streaming/Channels/101 | /Streaming/Channels/102 |
| Dahua, Amcrest | /cam/realmonitor?channel=1&subtype=0 | /cam/realmonitor?channel=1&subtype=1 |
| Reolink | /h264Preview_01_main | /h264Preview_01_sub |
| Axis | /axis-media/media.amp | /axis-media/media.amp?resolution=640×360 |
Die Hikvision-Nummerierung wird am häufigsten vertippt. Die drei Ziffern sind Kanal und Stream aneinandergehängt: aus 1 und 01 wird 101, der zweite Stream des ersten Kanals wird 102. Bei einer Kamera mit einem Objektiv ist der Kanal immer 1; in einem Gehäuse mit mehreren Sensoren heisst das zweite Objektiv 201 und 202.
Raten erübrigt sich, sobald die Kamera ONVIF spricht. Ein GetStreamUri-Aufruf liefert die Adresse, die die Kamera selbst für richtig hält, samt Pfad – und diese Antwort schlägt jede Tabelle.
Passwörter, die die Adresse zerlegen
Die Zugangsdaten stehen zwischen Schema und Host, getrennt durch einen Doppelpunkt und abgeschlossen durch ein At-Zeichen. Genau dort sitzt der stillste Fehler: Ein Passwort mit At-Zeichen, Doppelpunkt, Schrägstrich oder Rautezeichen beendet die Zugangsdaten zu früh, und der Rest des Passworts wird als Hostname gelesen.
Die Abhilfe heisst Prozentkodierung. Aus einem At-Zeichen wird %40, aus einem Doppelpunkt %3A, aus einem Schrägstrich %2F, aus einer Raute %23, aus einem Fragezeichen %3F. Ein Passwort Sommer@2026 erscheint in der Adresse also als Sommer%402026 und bleibt in der Kamera unverändert.
Zur anderen Seite dieser Sache gehört ein Hinweis: Viele Kameras melden über RTSP-Digest an, nicht über Basic Auth. Das Passwort läuft also nicht im Klartext über das Netz, obwohl es im Klartext in der Adresse steht. Im Klartext unterwegs ist dagegen die Adresse selbst – in der Shell-Historie, in einer Compose-Datei, in einer Logzeile. Zugangsdaten für eine Kamera gehören deshalb in ein eigenes Konto mit reinem Leserecht, nie in das Administratorkonto.
Die Adresse prüfen, bevor sie irgendwo eingetragen wird
Ein Befehl beantwortet die einzige Frage, die an dieser Stelle zählt. Er öffnet den Stream, liest die ersten Pakete, gibt aus, was er gefunden hat, und beendet sich.
ffprobe -hide_banner -rtsp_transport tcp \
-i "rtsp://admin:Sommer%402026@192.168.1.64:554/Streaming/Channels/102"Eine funktionierende Adresse gibt binnen ein bis zwei Sekunden eine Stream-Zeile mit Codec, Auflösung und Bildrate aus. Alles andere ist eine Diagnose, und die vier häufigen Antworten zeigen jeweils woandershin.
| Antwort | Bedeutung |
|---|---|
| 401 Unauthorized | Host und Pfad stimmen, die Zugangsdaten nicht – oder das Konto darf keinen Stream sehen |
| 404 Not Found | Zugangsdaten angenommen, Pfad falsch – ein Hersteller oder eine Stream-Nummer daneben |
| Connection refused | Auf 554 lauscht nichts; RTSP ist in der Kamera abgeschaltet oder der Port verschoben |
| Zeitüberschreitung nach dem Handshake | Die Sitzung steht, die Videopakete kommen nicht an – fast immer blockiertes UDP |
Die letzte der vier erklärt, warum -rtsp_transport tcp im Befehl steht. Voreingestellt läuft der Steuerkanal über TCP und das Video über UDP auf eigenen Ports. Über eine VLAN-Grenze oder eine Firewall hinweg gelingt deshalb der Handshake, und das Bild kommt trotzdem nie. Erzwungenes TCP kostet etwas Latenz und beseitigt eine ganze Fehlerklasse.
Welcher Stream wohin gehört
Sobald die Adresse funktioniert, erweist sich der Substream als die nützlichere Hälfte. Die Aufzeichnung braucht den Hauptstream, denn das ist das Material, das eine Versicherung oder ein Gericht ansieht. Bewegungsanalyse und Objekterkennung brauchen kleine Bilder und werden mit ihnen schneller: Ein Detektor, der 4K-Bilder bekommt, verbringt seine Zeit mit dem Verkleinern.
Frigate macht diese Trennung ausdrücklich, indem es je Stream eine Rolle vergibt – dieselbe Idee gilt für jeden Rekorder, der zwei Eingänge je Kamera annimmt.
cameras:
einfahrt:
ffmpeg:
inputs:
- path: rtsp://admin:Sommer%402026@192.168.1.64:554/Streaming/Channels/102
input_args: preset-rtsp-restream
roles: [detect]
- path: rtsp://admin:Sommer%402026@192.168.1.64:554/Streaming/Channels/101
input_args: preset-rtsp-restream
roles: [record]Zwei Verbindungen zu einer Kamera sind bei vielen Modellen zugleich die Obergrenze. Günstige Kameras erlauben vier gleichzeitige RTSP-Sitzungen, manchmal nur zwei, und der fünfte Versuch scheitert mit einer Meldung, die nichts mit der Adresse zu tun hat. Ein Restreamer wie go2rtc löst das, indem er eine Sitzung öffnet und allen anderen Kopien reicht.
Was später trotzdem noch bricht
Eine Adresse, die einmal funktioniert hat, kann aufhören zu funktionieren, ohne dass sich an ihr etwas geändert hätte. Drei Ursachen decken fast alles ab.
Die erste ist DHCP. Eine Kamera, die über ihre geliehene IP angesprochen wird, wandert nach einem Router-Neustart, und die Adresse zeigt auf das, was die Nummer übernommen hat. Eine Reservierung im DHCP-Server oder eine feste Adresse in der Kamera beendet das dauerhaft.
Die zweite ist eine Firmware-Aktualisierung, die den RTSP-Schalter oder das Zuschauerkonto zurücksetzt. Beides lohnt sich nach einer Aktualisierung zuerst zu prüfen, denn das Symptom – erst Connection refused, dann 401 – sieht nach einem Netzfehler aus.
Die dritte ist Zeit. Viele Kameras verwerfen eine Sitzung, die ohne RTCP-Rückmeldung liegen bleibt, und manche Rekorder senden diese nie. Das sieht so aus: Ein Stream läuft stundenlang und verschwindet nachts, jedes Mal zu einer etwas anderen Uhrzeit. Ein Restreamer mit Wiederverbindung beseitigt das Symptom, ein Keepalive-Intervall unterhalb der Zeitschwelle der Kamera die Ursache.
Passend dazu
