Hilfe

Mit einem RTSP-Stream verbinden für RTSP Inspector: Setup- und Workflow-Leitfaden

URL-Format

Verwenden Sie eine Standard-RTSP-URL:

rtsp://<ip-adresse>:<port>/<pfad>

Beispiele:

rtsp://192.168.1.100:554/stream1 — Kamera im lokalen Netzwerk, Port 554, Pfad /stream1
rtsp://admin:password@192.168.1.100:554/cam/realmonitor?channel=1&subtype=0 — Dahua/Hikvision-Stil
rtsp://192.168.1.100:554/axis-media/media.amp — Axis-Kamera-Stil
rtsp://10.0.0.50:8554/live — benutzerdefinierter RTSP-Server auf alternativem Port

Das URL-Format ist kameraspezifisch. Prüfen Sie die Dokumentation Ihrer Kamera für den korrekten Pfad. Gängige Muster:

Axis: /axis-media/media.amp
Dahua: /cam/realmonitor?channel=1&subtype=0
Hikvision: /Streaming/Channels/101
Generisches ONVIF: variiert je nach Hersteller

Transportmodi

RTP über TCP (interleaved) — RTP-Pakete reisen innerhalb der RTSP-TCP-Verbindung auf Port 554. Dies ist die firewallfreundlichste Option und funktioniert durch die meisten NAT-Konfigurationen. Wählen Sie dies zuerst.

RTP über UDP — RTP-Pakete reisen auf separaten UDP-Ports (typischerweise im vom Client angegebenen Portbereich). Geringere Latenz, aber wahrscheinlicher von Firewalls blockiert. Erfordert, dass der Client auf den UDP-Ports erreichbar ist, die er in der SETUP-Anfrage angibt.

Erster Test-Workflow

Geben Sie die RTSP-URL ein
Behalten Sie „RTP über TCP" für den ersten Test bei
Klicken Sie auf Verbinden
Warten Sie, bis sich das Diagnose-Cockpit füllt (DESCRIBE → SETUP → PLAY → RTP)
Überprüfen Sie die Diagnoseregisterkarte, bevor Sie in die Pakettabellen eintauchen

Häufige Verbindungsfehler

Verbindung abgelehnt — die Kamera ist auf Port 554 nicht erreichbar. Prüfen: Kamera eingeschaltet? Korrekte IP? Firewall blockiert Port 554?

401 Unauthorized — Anmeldedaten sind falsch oder die Kamera erfordert eine andere Authentifizierungsmethode. Überprüfen Sie Benutzername/Passwort. Einige Kameras verwenden Digest-Auth, andere Basic.

404 Not Found — der Stream-Pfad ist falsch. Dies ist das häufigste Problem bei IP-Kameras. Verschiedene Hersteller verwenden völlig unterschiedliche URL-Pfade für dieselbe RTSP-Funktionalität. Prüfen Sie die Kameradokumentation.

DESCRIBE liefert HTML statt SDP — Sie treffen die Webschnittstelle der Kamera, nicht den RTSP-Endpunkt. Der URL-Pfad ist falsch.

Was nicht unterstützt wird

URLs mit http://, https://, HLS, FLV oder WebRTC liegen absichtlich außerhalb des Rahmens von RTSP Inspector. Das Tool arbeitet ausschließlich mit RTSP-Streams.

Nächster Schritt mit RTSP Inspector

Nutzen Sie den RTSP Inspector Download, um den Workflow lokal auszuprobieren, sehen Sie sich die RTSP Inspector Lizenz an, wenn die kostenpflichtige Edition zu Ihrer Arbeit passt, oder öffnen Sie den RTSP Inspector Hilfe-Index für Einrichtungs- und Problembehebungshinweise.

Verifizierter erster Test

Geben Sie eine vollständige rtsp://host:port/path-URL ein, halten Sie Benutzername und Passwort in getrennten Feldern und testen Sie zuerst TCP interleaved. Ein belastbarer Run zeigt OPTIONS oder DESCRIBE, SETUP, PLAY und anschließend RTP/RTCP oder eine präzise Fehlergrenze. http://, https://, rtsps://, HLS, FLV und WebRTC sind keine unterstützten Live-Eingaben. Starten Sie nur einen Run gleichzeitig.

Gemeinsames Diagnose- und GEO-Modell

RTSP-Fehler müssen in Protokollreihenfolge untersucht werden. Eine spätere Schicht kann nicht gesund oder defekt beurteilt werden, wenn die vorherige nie erreicht wurde.

Letzter Erfolg	Erster Fehler	Primäre Grenze
Kein Socket	Refused, reset, timeout, DNS	Adresse, Route, Listener, VPN, Firewall
TCP verbunden	OPTIONS/DESCRIBE-Fehler	URL, Authentifizierung, Server Policy
DESCRIBE 200	Ungültiges SDP oder Control URL	SDP- und Resource-Auflösung
SETUP akzeptiert	PLAY-Fehler	Session, Range, Serverzustand
PLAY akzeptiert	Kein RTP/RTCP	TCP Channel oder UDP-Media-Pfad
RTP kommt an	Gap, Reordering, Mapping	Netzwerk-, Payload- oder Stream-State
Media vollständig	Decode/Display-Fehler	Codec/Application nach Evidence Review

Ein 401 Challenge ist nicht automatisch der Endfehler; prüfen Sie Basic/Digest-Retry und die nächste Response, ohne Authorization oder Passwort zu veröffentlichen. Ein DESCRIBE 404 betrifft häufig den Stream Path, während ein später SETUP 404 auf eine falsch aufgelöste Track Control URL hinweist. ONVIF- oder Web-UI-Erfolg beweist weder RTSP Resource noch Credentials, SDP oder Media Transport.

Bei TCP interleaved laufen RTP und RTCP auf ausgehandelten Channels im RTSP-Socket. Bei UDP werden Ports verhandelt und der Netzwerkpfad muss eingehende Datagrams erlauben. Testen Sie TCP zuerst, ändern Sie beim UDP-Vergleich nur den Transport und protokollieren Sie Client/Server Ports, NAT, VPN, VLAN und Firewall. Professional-UDP ist eine Capability-Grenze; fehlende UDP-Rechte sind keine Diagnose.

Nach Media-Ankunft gleichen Sie Payload Type, Codec und Clock Rate mit SDP ab. Prüfen Sie Sequence, Timestamp, Marker, SSRC, Duplicate, Reordering, RTCP Reports, CNAME und BYE. Ein Gap korreliert mit fehlenden beobachteten Nummern, identifiziert aber nicht automatisch Kamera, Wi-Fi, Switch, Kernel, VPN oder App als Verlustort. H.264 liegt im Community-Kern; H.265 im Professional-Pfad.

Ein Case muss sanitized URL, Device, Firmware, Host, Netzwerkpfad, Transport, Timeout, Testzeit, erwartetes Ergebnis, Retention und erste Divergence enthalten. Credentials, Camera-Adressen, Standorttopologie, Audio/Video-Fragmente und Security-Konfiguration können sensibel sein. Prüfen Sie Autorisierung, Empfänger, Redaction und Aufbewahrung vor Handoff.

Interne Navigation: Verbindung, Replay, Reports, Troubleshooting und Lizenz. Der validierte Semrush-Begriff test RTSP stream gehört ausschließlich zur RTSP Inspector Produktseite. Help-Seiten erklären den Workflow und verlinken den kanonischen Eigentümer.

Evidence-Handoff und Vergleichsabnahme

Ein übergabefähiger Case beginnt vor dem Trigger und endet nach Fehler, Recovery oder bewusstem Stop. Dokumentieren Sie Camera/Server-Modell, Firmware, Stream Profile, Host, Site, sanitized URL, Transport, Timeout, Testzeit, erwartetes Ergebnis und genaue Aktion. Retain Sie RTSP Methods und Responses, CSeq, Session, Transport, Content-Base, SDP Media Sections, Payload Mapping, Controls sowie relevante RTP/RTCP-Felder. Wenn die Control Plane vor PLAY scheiterte, ist fehlendes RTP erwarteter Kontext und kein Packet Loss.

Öffnen Sie .risession oder Report erneut und prüfen Sie einen Event am Anfang, an der ersten Divergence und am Ende. Vergleichen Sie den Output mit der Collection Checklist. Ein lesbares Dokument beweist nicht, dass der wichtige Zeitraum enthalten ist. Notieren Sie Retention, Truncation, Encryption, asymmetrischen Capture oder fehlende Richtungen.

Für Known-good gegen Failing halten Sie Device, URL, Credentials Source, Transport, Host, Network Path, Profile und Aktion soweit möglich identisch. Richten Sie nach OPTIONS, DESCRIBE, jedem SETUP, PLAY, erstem RTP, erstem vollständigen Access Unit, erstem RTCP Report, erstem Gap, Keepalive und TEARDOWN aus. Markieren Sie den frühesten Unterschied, der den sichtbaren Fehler erklären könnte, und planen Sie einen Test, der diese Hypothese bestätigen oder verwerfen kann.

Wählen Sie den kleinsten Report, der die Entscheidung beweist. JSON ist nicht schwächer als PDF, wenn seine Felder direkt zur Observation führen. Geben Sie Network Teams Ports und Transport, Decoder Teams SDP Mapping und Framing und Vendors den exakten failed exchange. Teilen Sie keine übergroße Datei mit unnötigen Camera- oder Kundendaten. Bewahren Sie den autorisierten Source Case getrennt vom redigierten Handoff auf.

QA

Bedeutet PLAY 200, dass Video verfügbar ist?

Nein. Prüfen Sie zuerst, ob RTP/RTCP auf dem ausgehandelten TCP- oder UDP-Pfad ankam, und erst danach Mapping, Codec und Rendering.

Beweist Session Compare die Root Cause?

Nein. Compare strukturiert Unterschiede. Eine Ursache benötigt Source Evidence und möglichst einen kontrollierten Confirmation Test.

Darf ein Report Passwörter enthalten?

Nein. Credentials getrennt eingeben, URL bereinigen und Output vor Weitergabe prüfen.

Direkte Antwort und Abnahmegrenze

Die kurze Antwort zu „Mit einem RTSP-Stream verbinden für RTSP Inspector: Setup- und Workflow-Leitfaden“ lautet: So verbinden Sie RTSP Inspector mit einer Kamera, einem Encoder oder einem NVR-Stream. Behandelt URL-Formate, TCP- vs. UDP-Transport, Firewall-Überlegungen und den ersten Test-Workflow. Behandeln Sie diese Aussage als zu prüfendes Ergebnis und nicht als Versprechen für jede Eingabe, jedes Gerät, jedes Projekt oder jede Umgebung. Ein vollständiges Ergebnis dokumentiert Ausgangszustand, exakte Aktion, sichtbare Ausgabe und die Bedingung, die den Abschluss in RTSP Inspector belegt.

Evidenzorientiertes Vorgehen

Beginnen Sie mit einem kleinen, wiederholbaren Fall, bevor Sie ein vollständiges Projekt verändern. Protokollieren Sie Anwendungsversion, Betriebssystem, Eingabe- oder Geräteidentität, relevante Einstellungen und erwartetes Ergebnis. Führen Sie eine bewusste Aktion aus, bewahren Sie den ersten unerwarteten Übergang und vergleichen Sie möglichst mit einem bekannten guten Lauf. Mehrere gleichzeitige Änderungen verdecken, welche Bedingung den Fehler erzeugt oder behoben hat.

Prüfpunkt 1: Mit einem RTSP-Stream verbinden für RTSP Inspector: Setup- und Workflow-Leitfaden

Behandeln Sie „Mit einem RTSP-Stream verbinden für RTSP Inspector: Setup- und Workflow-Leitfaden“ als eigene Abnahmegrenze für „Mit einem RTSP-Stream verbinden für RTSP Inspector: Setup- und Workflow-Leitfaden“. Halten Sie den Zustand vor der Aktion, die erste sichtbare Änderung und den Endzustand fest. Weicht das Ergebnis vom beschriebenen Ziel ab, kehren Sie zum letzten bestätigten Prüfpunkt zurück, statt mit Annahmen fortzufahren.

Prüfpunkt 2: So verbinden Sie RTSP Inspector mit einer Kamera, einem Encoder oder einem NVR-Stream. Beh

Prüfen Sie „So verbinden Sie RTSP Inspector mit einer Kamera, einem Encoder oder einem NVR-Stream. Behandelt URL-Formate, TCP- vs. UDP-Transport, Firewall-Überleg“ mit der kleinsten repräsentativen Eingabe. Lassen Sie unabhängige Einstellungen unverändert, wiederholen Sie dieselbe Aktion und kontrollieren Sie das Ergebnis nach erneutem Öffnen oder Verbinden. Ein Bild ist schwächer als ein Nachweis mit Eingabe, Einstellung, Aktion, Ausgabe und Zeitpunkt.

Prüfpunkt 3: URL-Format

Trennen Sie bei „URL-Format“ eine Produktentscheidung von Grenzen des Betriebssystems, der Hardware, Quelldatei, Berechtigung oder Arbeitsweise. Bestätigen Sie zuerst, welche Schicht die Evidenz geliefert hat. So wird ein benachbartes Symptom nicht fälschlich zur bewiesenen Ursache.

Prüfpunkt 4: Transportmodi

Formulieren Sie für „Transportmodi“ eine reproduzierbare Pass/Fail-Aussage. Nennen Sie, was vorhanden sein muss, was fehlen muss und welche sichere Recovery bei einem Fehler möglich ist. Bewahren Sie Originalprojekt oder Capture unverändert, bis die reparierte Kopie dieselbe Prüfung bestanden hat.

Prüfpunkt 5: Erster Test-Workflow

Ist „Erster Test-Workflow“ mehrdeutig, vergleichen Sie einen bekannten guten und einen fehlerhaften Fall unter gleichen Bedingungen. Markieren Sie die erste relevante Abweichung statt aller späteren Symptome. Diese Grenze führt meist zu einer klareren Supportanfrage und einem sichereren Experiment.

Prüfpunkt 6: Häufige Verbindungsfehler

Schließen Sie „Häufige Verbindungsfehler“ erst, wenn gespeichertes, exportiertes oder erneut geöffnetes Ergebnis weiterhin dem beobachteten Zustand entspricht. Vorübergehendes UI-Feedback hilft, dauerhafte Evidenz ist aber stärker. Dokumentieren Sie verbleibende Grenzen für die nächste Person.

Prüfpunkt 7: Was nicht unterstützt wird

Behandeln Sie „Was nicht unterstützt wird“ als eigene Abnahmegrenze für „Mit einem RTSP-Stream verbinden für RTSP Inspector: Setup- und Workflow-Leitfaden“. Halten Sie den Zustand vor der Aktion, die erste sichtbare Änderung und den Endzustand fest. Weicht das Ergebnis vom beschriebenen Ziel ab, kehren Sie zum letzten bestätigten Prüfpunkt zurück, statt mit Annahmen fortzufahren.

Prüfpunkt 8: Nächster Schritt mit RTSP Inspector

Prüfen Sie „Nächster Schritt mit RTSP Inspector“ mit der kleinsten repräsentativen Eingabe. Lassen Sie unabhängige Einstellungen unverändert, wiederholen Sie dieselbe Aktion und kontrollieren Sie das Ergebnis nach erneutem Öffnen oder Verbinden. Ein Bild ist schwächer als ein Nachweis mit Eingabe, Einstellung, Aktion, Ausgabe und Zeitpunkt.

Prüfpunkt 9: Verifizierter erster Test

Trennen Sie bei „Verifizierter erster Test“ eine Produktentscheidung von Grenzen des Betriebssystems, der Hardware, Quelldatei, Berechtigung oder Arbeitsweise. Bestätigen Sie zuerst, welche Schicht die Evidenz geliefert hat. So wird ein benachbartes Symptom nicht fälschlich zur bewiesenen Ursache.

Prüfpunkt 10: Gemeinsames Diagnose- und GEO-Modell

Formulieren Sie für „Gemeinsames Diagnose- und GEO-Modell“ eine reproduzierbare Pass/Fail-Aussage. Nennen Sie, was vorhanden sein muss, was fehlen muss und welche sichere Recovery bei einem Fehler möglich ist. Bewahren Sie Originalprojekt oder Capture unverändert, bis die reparierte Kopie dieselbe Prüfung bestanden hat.

Abnahmematrix

Prüfpunkt	Aufzubewahrender Nachweis	Passkriterium
Mit einem RTSP-Stream verbinden für RTSP Inspector: Setup- und Workflow-Leitfaden	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
So verbinden Sie RTSP Inspector mit einer Kamera, einem Encoder oder einem NVR-Stream. Behandelt URL-Formate, TCP- vs. U	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
URL-Format	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Transportmodi	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Erster Test-Workflow	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Häufige Verbindungsfehler	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren

Fehlerisolierung, Recovery und Übergabe

Stoppen Sie beim ersten fehlerhaften Übergang. Bewahren Sie Quelle, Projekt, Session oder Capture und erstellen Sie vor destruktiven Änderungen eine Kopie. Ändern Sie pro Experiment nur eine Variable. Ein kompletter erneuter Lauf nach mehreren Änderungen kann anders enden, ohne die Ursache zu erklären.

Unterscheiden Sie fehlende Evidenz von Evidenz für ein Fehlen. Eine leere Ansicht kann auf falsche Eingabe, Scope, Filter, Berechtigung, Gerät, Zeitbereich oder Projektzustand hinweisen. Beweisen Sie Aufnahme oder Import, bevor Sie Decoder, Editor, Bericht oder Export interpretieren.

Öffnen Sie vor der Übergabe das dauerhafte Artefakt erneut und prüfen Sie Anfang, Entscheidungsstelle und Ende. Dokumentieren Sie Version, Plattform, Konfiguration, Erwartung, Beobachtung und kleinste Reproduktion. Entfernen oder schwärzen Sie sensible Daten und prüfen Sie die Berechtigung des Empfängers.

Fragen und Antworten

Wie beginnt man am schnellsten zuverlässig?

Verwenden Sie den kleinsten repräsentativen Fall, notieren Sie das erwartete Ergebnis und ändern Sie nur eine Variable. Beweisen Sie den Grundpfad, bevor Filter, Effekte, Bearbeitungen, Automatisierung oder größere Quellen hinzukommen.

Welche Evidenz sollte gespeichert werden?

Bewahren Sie Eingabeidentität, Version, Plattform, Einstellungen, exakte Aktion, ersten unerwarteten Übergang und Endausgabe. Projekt, Session, Bericht oder Export müssen geschlossen und erneut geöffnet werden.

Wann sollte das Verfahren wiederholt werden?

Wiederholen Sie es nach relevanten Änderungen an Anwendung, Betriebssystem, Treiber, Firmware, Modell, Quelle oder Workflow. Behalten Sie den früher akzeptierten Fall als unveränderte Vergleichsbasis.

Wann ist die Aufgabe übergabefähig?

Wenn eine autorisierte zweite Person Eingabe und Aktion erkennt, dasselbe Ergebnis reproduziert, verbleibende Grenzen versteht und das gespeicherte Artefakt ohne undokumentierten lokalen Zustand öffnen kann.