![\"Eine](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/rtsp-adressen-de.png\")
Die sechs Teile einer Stream-Adresse<\/h2>\n
Eine RTSP-Adresse ist gebaut wie eine Webadresse: Schema, Zugangsdaten, Host, Port, Pfad und auf manchen Kameras eine Abfragezeichenfolge, die die Stream-Nummer tr\u00e4gt.<\/p>\n
rtsp:\/\/admin:Sommer%402026@192.168.1.64:554\/Streaming\/Channels\/102\nrtsp:\/\/admin:Sommer%402026@192.168.1.64:554\/cam\/realmonitor?channel=1&subtype=1\nrtsps:\/\/192.168.1.1:7441\/aBcD1234EfGh?enableSrtp<\/code><\/pre>\nDas Schema lautet rtsp<\/code> und der Port 554, solange ihn niemand verschoben hat. Ubiquiti ist die Ausnahme, die im Ged\u00e4chtnis bleiben sollte: UniFi Protect antwortet auf rtsps<\/code> an Port 7441, lehnt einfaches RTSP ab und vergibt statt eines lesbaren Pfads eine undurchsichtige Kennung. Diese Kennung erscheint erst, nachdem RTSP f\u00fcr die einzelne Kamera in Protect eingeschaltet wurde.<\/p>\nHost 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.<\/p>\n
Warum der Pfad auf jeder Kamera anders heisst<\/h2>\n
Der Pfad tr\u00e4gt zwei Angaben, f\u00fcr die RTSP selbst kein Feld vorsieht: welches Objektiv und welcher seiner Streams. Fast jede Kamera bietet mindestens zwei – einen Hauptstream in voller Aufl\u00f6sung f\u00fcr die Aufzeichnung und einen Substream mit einem Viertel davon f\u00fcr Vorschau und Bewegungsanalyse.<\/p>\n
\n\n\nHersteller<\/th>\n Hauptstream<\/th>\n Substream<\/th>\n<\/tr>\n<\/thead>\n \n\nHikvision<\/td>\n \/Streaming\/Channels\/101<\/td>\n \/Streaming\/Channels\/102<\/td>\n<\/tr>\n \nDahua, Amcrest<\/td>\n \/cam\/realmonitor?channel=1&subtype=0<\/td>\n \/cam\/realmonitor?channel=1&subtype=1<\/td>\n<\/tr>\n \nReolink<\/td>\n \/h264Preview_01_main<\/td>\n \/h264Preview_01_sub<\/td>\n<\/tr>\n \nAxis<\/td>\n \/axis-media\/media.amp<\/td>\n \/axis-media\/media.amp?resolution=640×360<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nDie Hikvision-Nummerierung wird am h\u00e4ufigsten vertippt. Die drei Ziffern sind Kanal und Stream aneinandergeh\u00e4ngt: 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\u00e4use mit mehreren Sensoren heisst das zweite Objektiv 201 und 202.<\/p>\n
Raten er\u00fcbrigt sich, sobald die Kamera ONVIF spricht. Ein GetStreamUri<\/code>-Aufruf liefert die Adresse, die die Kamera selbst f\u00fcr richtig h\u00e4lt, samt Pfad – und diese Antwort schl\u00e4gt jede Tabelle.<\/p>\nPassw\u00f6rter, die die Adresse zerlegen<\/h2>\n
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\u00e4gstrich oder Rautezeichen beendet die Zugangsdaten zu fr\u00fch, und der Rest des Passworts wird als Hostname gelesen.<\/p>\n
Die Abhilfe heisst Prozentkodierung. Aus einem At-Zeichen wird %40<\/code>, aus einem Doppelpunkt %3A<\/code>, aus einem Schr\u00e4gstrich %2F<\/code>, aus einer Raute %23<\/code>, aus einem Fragezeichen %3F<\/code>. Ein Passwort Sommer@2026<\/code> erscheint in der Adresse also als Sommer%402026<\/code> und bleibt in der Kamera unver\u00e4ndert.<\/p>\nZur anderen Seite dieser Sache geh\u00f6rt ein Hinweis: Viele Kameras melden \u00fcber RTSP-Digest an, nicht \u00fcber Basic Auth. Das Passwort l\u00e4uft also nicht im Klartext \u00fcber 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\u00fcr eine Kamera geh\u00f6ren deshalb in ein eigenes Konto mit reinem Leserecht, nie in das Administratorkonto.<\/p>\n
Die Adresse pr\u00fcfen, bevor sie irgendwo eingetragen wird<\/h2>\n
Ein Befehl beantwortet die einzige Frage, die an dieser Stelle z\u00e4hlt. Er \u00f6ffnet den Stream, liest die ersten Pakete, gibt aus, was er gefunden hat, und beendet sich.<\/p>\n
ffprobe -hide_banner -rtsp_transport tcp \\\n -i \"rtsp:\/\/admin:Sommer%402026@192.168.1.64:554\/Streaming\/Channels\/102\"<\/code><\/pre>\nEine funktionierende Adresse gibt binnen ein bis zwei Sekunden eine Stream-Zeile mit Codec, Aufl\u00f6sung und Bildrate aus. Alles andere ist eine Diagnose, und die vier h\u00e4ufigen Antworten zeigen jeweils woandershin.<\/p>\n
\n\n\nAntwort<\/th>\n Bedeutung<\/th>\n<\/tr>\n<\/thead>\n \n\n401 Unauthorized<\/td>\n Host und Pfad stimmen, die Zugangsdaten nicht – oder das Konto darf keinen Stream sehen<\/td>\n<\/tr>\n \n404 Not Found<\/td>\n Zugangsdaten angenommen, Pfad falsch – ein Hersteller oder eine Stream-Nummer daneben<\/td>\n<\/tr>\n \nConnection refused<\/td>\n Auf 554 lauscht nichts; RTSP ist in der Kamera abgeschaltet oder der Port verschoben<\/td>\n<\/tr>\n \nZeit\u00fcberschreitung nach dem Handshake<\/td>\n Die Sitzung steht, die Videopakete kommen nicht an – fast immer blockiertes UDP<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nDie letzte der vier erkl\u00e4rt, warum -rtsp_transport tcp<\/code> im Befehl steht. Voreingestellt l\u00e4uft der Steuerkanal \u00fcber TCP und das Video \u00fcber UDP auf eigenen Ports. \u00dcber 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.<\/p>\nWelcher Stream wohin geh\u00f6rt<\/h2>\n
Sobald die Adresse funktioniert, erweist sich der Substream als die n\u00fctzlichere H\u00e4lfte. 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.<\/p>\n
Frigate macht diese Trennung ausdr\u00fccklich, indem es je Stream eine Rolle vergibt – dieselbe Idee gilt f\u00fcr jeden Rekorder, der zwei Eing\u00e4nge je Kamera annimmt.<\/p>\n
cameras:\n einfahrt:\n ffmpeg:\n inputs:\n - path: rtsp:\/\/admin:Sommer%402026@192.168.1.64:554\/Streaming\/Channels\/102\n input_args: preset-rtsp-restream\n roles: [detect]\n - path: rtsp:\/\/admin:Sommer%402026@192.168.1.64:554\/Streaming\/Channels\/101\n input_args: preset-rtsp-restream\n roles: [record]<\/code><\/pre>\nZwei Verbindungen zu einer Kamera sind bei vielen Modellen zugleich die Obergrenze. G\u00fcnstige Kameras erlauben vier gleichzeitige RTSP-Sitzungen, manchmal nur zwei, und der f\u00fcnfte Versuch scheitert mit einer Meldung, die nichts mit der Adresse zu tun hat. Ein Restreamer wie go2rtc l\u00f6st das, indem er eine Sitzung \u00f6ffnet und allen anderen Kopien reicht.<\/p>\n
Was sp\u00e4ter trotzdem noch bricht<\/h2>\n
Eine Adresse, die einmal funktioniert hat, kann aufh\u00f6ren zu funktionieren, ohne dass sich an ihr etwas ge\u00e4ndert h\u00e4tte. Drei Ursachen decken fast alles ab.<\/p>\n
Die erste ist DHCP. Eine Kamera, die \u00fcber ihre geliehene IP angesprochen wird, wandert nach einem Router-Neustart, und die Adresse zeigt auf das, was die Nummer \u00fcbernommen hat. Eine Reservierung im DHCP-Server oder eine feste Adresse in der Kamera beendet das dauerhaft.<\/p>\n
Die zweite ist eine Firmware-Aktualisierung, die den RTSP-Schalter oder das Zuschauerkonto zur\u00fccksetzt. Beides lohnt sich nach einer Aktualisierung zuerst zu pr\u00fcfen, denn das Symptom – erst Connection refused, dann 401 – sieht nach einem Netzfehler aus.<\/p>\n
Die dritte ist Zeit. Viele Kameras verwerfen eine Sitzung, die ohne RTCP-R\u00fcckmeldung liegen bleibt, und manche Rekorder senden diese nie. Das sieht so aus: Ein Stream l\u00e4uft 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.<\/p>\n