{"id":12949,"date":"2026-09-09T12:45:00","date_gmt":"2026-09-09T10:45:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=12949"},"modified":"2026-10-24T06:04:55","modified_gmt":"2026-10-24T04:04:55","slug":"tutorial-rtsp-adressen-fur-ip-kameras-bauen-und-prufen","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/cctv-de\/tutorials-de-cctv-de\/tutorial-rtsp-adressen-fur-ip-kameras-bauen-und-prufen\/","title":{"rendered":"Tutorial: RTSP-Adressen f\u00fcr IP-Kameras bauen und pr\u00fcfen"},"content":{"rendered":"

Eine RTSP-Adresse bezeichnet einen Mediendienst und den gew\u00fcnschten Stream. RTSP steuert die Sitzung; die Videodaten werden h\u00e4ufig in RTP-Paketen \u00fcbertragen. Unterst\u00fctzung, Pfade, Anmeldung und Transportm\u00f6glichkeiten h\u00e4ngen von Modell und Firmware ab. Eine erfolgreiche Verbindung ist der erste Pr\u00fcfschritt, kein Nachweis einer zuverl\u00e4ssigen Aufzeichnung.<\/p>\n

1. Den tats\u00e4chlichen Server bestimmen<\/h2>\n

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 \u00fcbliche RTSP-Standardport; ma\u00dfgeblich bleibt der konfigurierte Port.<\/p>\n

\"RTSP:
Ein Statuscode ist ein Hinweis, keine vollst\u00e4ndige Diagnose<\/figcaption><\/figure>\n

Die folgende erfundene Adresse zeigt die Bestandteile. Zugangsdaten in der URL sind eine vom Client unterst\u00fctzte Konvention, deren Kompatibilit\u00e4t gepr\u00fcft werden muss. Getrennte Zugangsdatenfelder sind vorzuziehen, sofern vorhanden.<\/p>\n

rtsp:\/\/viewer:Example%402026@192.0.2.10:554\/Streaming\/Channels\/102\nSchema | Nutzer:Passwort     | Host      | Port | Pfad<\/code><\/pre>\n
Weder Host noch Zugangsdaten oder Port sind bei allen Kameras identisch. Eine ausgeschriebene IPv6-Adresse ben\u00f6tigt eckige Klammern, etwa rtsp:\/\/[2001:db8::10]:554\/stream<\/code>. Eine Abfragezeichenfolge kann weitere Einstellungen ausw\u00e4hlen. Die genaue Bedeutung ergibt sich aus der Ger\u00e4tedokumentation.<\/p>\n
2. Den Pfad aus Ger\u00e4t oder Dokumentation \u00fcbernehmen<\/h2>\n\n\n\n\n\n\n\n\n
Ger\u00e4tefamilie<\/th>\nBeispielpfad<\/th>\n<\/tr>\n<\/thead>\n
Hikvision<\/td>\n\/Streaming\/channels\/101 \u00b7 \/Streaming\/channels\/102<\/code><\/td>\n<\/tr>\n
Amcrest IP<\/td>\n\/cam\/realmonitor?channel=1&subtype=0<\/code><\/td>\n<\/tr>\n
Reolink<\/td>\n\/Preview_01_main \u00b7 \/Preview_01_sub<\/code><\/td>\n<\/tr>\n
Axis<\/td>\n\/axis-media\/media.amp?streamprofile=PROFILE<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
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\u00e4tzlich ein physisches Objektiv. Der Axis-Parameter f\u00fcr die Aufl\u00f6sung fordert eine unterst\u00fctzte Gr\u00f6\u00dfe an und benennt nicht automatisch einen festen \u201eSubstream\u201c.<\/p>\n
Bei einem kompatiblen ONVIF-Mediendienst ermittelt GetProfiles<\/code> die verf\u00fcgbaren Medienprofile. GetStreamUri<\/code> fordert eine URI f\u00fcr das gew\u00e4hlte Profil und den Transport an. Anmeldung, Erreichbarkeit und Clientkompatibilit\u00e4t bleiben zu pr\u00fcfen. Eine zur\u00fcckgegebene private Adresse ist nicht automatisch aus einem anderen Netz erreichbar.<\/p>\n
Ubiquitis offizielle Port\u00fcbersicht f\u00fchrt f\u00fcr Protect sowohl RTSPS auf 7441 als auch RTSP auf 7447 auf. Die fr\u00fchere Behauptung einer grunds\u00e4tzlichen Ablehnung von unverschl\u00fcsseltem RTSP war zu weitgehend. Die konfigurierte, unterst\u00fctzte Exportadresse und Konsolenversion haben Vorrang vor geratenen URL-Umbauten.<\/p>\n
3. Zugangsdaten kodieren, Kodierung nicht mit Verschl\u00fcsselung verwechseln<\/h2>\n
Reservierte Zeichen k\u00f6nnen die Zerlegung einer URL ver\u00e4ndern. Nutzername und Passwort werden getrennt kodiert: @ \u2192 %40<\/code>, \/ \u2192 %2F<\/code>, # \u2192 %23<\/code>, ? \u2192 %3F<\/code>, % \u2192 %25<\/code> und Leerzeichen \u2192 %20<\/code>. Ein Doppelpunkt als %3A<\/code> vermeidet Mehrdeutigkeit; ein Doppelpunkt innerhalb der Nutzerinformation beendet dieses Feld aber nicht grunds\u00e4tzlich. Bereits kodierte Werte d\u00fcrfen nicht erneut kodiert werden.<\/p>\n
Prozentkodierung ist umkehrbar und bietet keine Geheimhaltung. Digest-Anmeldung \u00fcbertr\u00e4gt das Passwort selbst nicht im Klartext. Das verschl\u00fcsselt jedoch nicht das Video. Au\u00dferdem verwenden nicht alle Kameras Digest. Basic-Anmeldung ohne Transportschutz legt wiederherstellbare Zugangsdaten offen. RTSPS sch\u00fctzt die Steuerverbindung mit TLS; der Schutz der Medien h\u00e4ngt vom ausgehandelten Transport ab.<\/p>\n
Ein eigenes Zuschauerkonto begrenzt Berechtigungen. URLs und Kennungen bleiben in Prozessargumenten, Protokollen und Konfigurationen vertraulich zu behandeln. Lokale Kodierung vermeidet die \u00dcbertragung echter Passw\u00f6rter an einen Online-Kodierer.<\/p>\n
4. Metadaten mit einer Zeitgrenze pr\u00fcfen<\/h2>\n
Das Bash-Beispiel ben\u00f6tigt ffprobe und GNU timeout<\/code>. Die URL wird ohne Terminalanzeige eingelesen. Anschlie\u00dfend 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\u00f6ste Argument kann trotzdem bei berechtigter Prozessabfrage oder in Fehlermeldungen sichtbar werden.<\/p>\n
IFS= read -r -s -p 'RTSP URL: ' RTSP_URL\nprintf '\\n'\ntimeout -k 2s 15s ffprobe -v error \\\n  -rtsp_transport tcp -timeout 5000000 \\\n  -select_streams v:0 \\\n  -show_entries stream=codec_name,width,height,avg_frame_rate \\\n  -of json "$RTSP_URL"\nprobe_status=$?\nunset RTSP_URL\nprintf 'Exit status: %s\\n' "$probe_status"<\/code><\/pre>\n
-timeout 5000000<\/code> begrenzt RTSP-Socket-Wartezeiten in der gepr\u00fcften Version FFmpeg 7.1.5 auf f\u00fcnf Sekunden. Der \u00e4u\u00dfere Befehl setzt unabh\u00e4ngig davon eine Laufzeitgrenze von 15 Sekunden mit weiteren zwei Sekunden bis zum erzwungenen Ende. GNU timeout liefert bei Fristablauf gew\u00f6hnlich R\u00fcckgabewert 124. Eine g\u00fcltige Kamera muss deshalb nicht innerhalb von zwei Sekunden antworten.<\/p>\n
Codec und Bildgr\u00f6\u00dfe im JSON best\u00e4tigen brauchbare Metadaten, keine dauerhafte Paketlieferung oder erfolgreiche Dekodierung. Ein fehlender Videoeintrag ist kein bestandener Videotest. Danach pr\u00fcfen ein Player und eine repr\u00e4sentative Aufzeichnung tats\u00e4chliche Bilder, Bewegung, Tag\/Nacht-Wechsel und Wiederverbindung.<\/p>\n\n\n\n\n\n\n
401 Unauthorized<\/th>\nAnmeldung wird angefordert oder scheitert. Eine erste Anforderung kann normal sein; ein korrekter Pfad ist damit nicht bewiesen.<\/td>\n<\/tr>\n
404 Not Found<\/th>\nDie angeforderte Ressource wurde nicht gefunden. Daraus folgt keine best\u00e4tigte Annahme der Zugangsdaten.<\/td>\n<\/tr>\n
Connection refused<\/th>\nEndpunkt oder Zwischenkomponente weist die TCP-Verbindung zur\u00fcck. Ziel, konfigurierten Port, Dienst und Firewall pr\u00fcfen.<\/td>\n<\/tr>\n
Timeout<\/th>\nVerbindung oder Lesevorgang wurde nicht rechtzeitig fertig. Betroffenen Schritt, Transport, Route, Last und Protokolle untersuchen.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
TCP-\u00dcbertragung 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.<\/p>\n
5. Erkennung und Aufzeichnung bewusst aufteilen<\/h2>\n
Frigate erlaubt einen Eingang mit detect<\/code> und einen mit record<\/code>. Der Ausschnitt zeigt die Rollen f\u00fcr einen best\u00e4tigten Pfad im Hikvision-Stil. Die vollst\u00e4ndige Konfiguration ben\u00f6tigt zus\u00e4tzlich passende Aufzeichnungseinstellungen und eine Pr\u00fcfung mit der installierten Frigate-Version.<\/p>\n
cameras:\n  driveway:\n    ffmpeg:\n      inputs:\n        - path: "rtsp:\/\/{FRIGATE_RTSP_USER}:{FRIGATE_RTSP_PASSWORD}@192.0.2.10:554\/Streaming\/Channels\/102"\n          input_args: preset-rtsp-generic\n          roles: [detect]\n        - path: "rtsp:\/\/{FRIGATE_RTSP_USER}:{FRIGATE_RTSP_PASSWORD}@192.0.2.10:554\/Streaming\/Channels\/101"\n          input_args: preset-rtsp-generic\n          roles: [record]<\/code><\/pre>\n
Umgebungsvariablen werden nur in dokumentierten Konfigurationsfeldern ersetzt. Die Passwortvariable enth\u00e4lt hier den URL-kodierten Wert. Eine gesch\u00fctzte Umgebungsdatei reduziert versehentliches Weitergeben; Laufzeitwerte sind dadurch kein Geheimnisspeicher.<\/p>\n
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\u00e4chst 172,8 Pixel, bleiben nach Skalierung 28,8 Pixel. Beschnitt, Perspektive und Kodierung k\u00f6nnen das praktische Ergebnis ver\u00e4ndern. Daraus folgt keine Erkennungsgarantie.<\/p>\n
\n
Fragen und Antworten<\/h2>\n
Ben\u00f6tigt go2rtc grunds\u00e4tzlich nur eine Kameraverbindung?<\/h3>\n
Mehrere Abnehmer k\u00f6nnen einen eingehenden Stream teilen. Unterschiedliche Haupt- und Substreamquellen ben\u00f6tigen trotzdem m\u00f6glicherweise getrennte Kameraverbindungen. Die Sitzungsgrenzen h\u00e4ngen vom Modell ab; eine allgemeine Grenze von zwei oder vier Sitzungen ist unbelegt.<\/p>\n
Behebt eine DHCP-Reservierung jede sp\u00e4tere St\u00f6rung?<\/h3>\n
Eine Reservierung unterst\u00fctzt eine vorhersehbare Adresse. Adresskonflikte, Routing, Stromversorgung, Firmware, Diensteinstellungen und Konto\u00e4nderungen bleiben m\u00f6gliche Ursachen. Ein Routerneustart \u00e4ndert nicht zwangsl\u00e4ufig die bisherige Adresszuweisung.<\/p>\n
Warum endet ein Stream nach einiger Zeit?<\/h3>\n
Protokolle sollten Transportverlust, Sitzungsablauf und Neustarts von Client oder Ger\u00e4t unterscheiden. Unterst\u00fctzte RTSP-Keepalives und die Sitzungsfrist des Servers sind relevant; fehlende RTCP-R\u00fcckmeldungen sind nicht die einzige Erkl\u00e4rung. Automatische Wiederverbindung kann den Betrieb herstellen, ohne die urspr\u00fcngliche Ursache zu kl\u00e4ren.<\/p>\n<\/div>\n
\n
Quellen<\/h2>\n