2026-06-18

RTSP-Stream-Fehlerbehebung: Das vollständige Diagnosehandbuch für Kamera-Streams

Vollständiger RTSP-Diagnose-Workflow: Verbindungsschicht, Fehler der Steuerebene (400/401/404/454/461/500/503), Ausfälle der Medienebene (H.264/H.265/RTP/RTCP), Sitzungsverwaltung und Vergleich mit Wireshark/VLC. Jedes RTSP-Problem wird einer Diagnoseseite zugeordnet.

These problems happen before any RTSP command is sent. TCP handshake fails, TLS negotiation fails, or the network path is blocked.

RTSP connects but no video — The most common symptom. Camera appears online but no media stream.
RTSP over TLS (RTSPS) debugging — TLS certificate errors, handshake failures, cipher suite negotiation.

Steuerungsebene: RTSP-Befehlsfehler

Hierbei handelt es sich um Fehler auf Protokollebene, die von der Kamera als Reaktion auf DESCRIBE, SETUP oder PLAY zurückgegeben werden. Der Fehlercode sagt Ihnen genau, was schief gelaufen ist.

400 Ungültige Anfrage

RTSP 400 Bad Request: DESCRIBE failed – Fehlerhafte URL, nicht unterstützte Header, Proxy-Interferenz. Deckt die URL-Formate Axis, Dahua und Hikvision ab.

401 Nicht autorisiert

RTSP 401-Authentifizierungsschleife – Digest vs. Basisauthentifizierung, Nonce-/Realm-Parameter, warum die Authentifizierung in VLC erfolgreich ist, in Ihrer App jedoch fehlschlägt.
Detaillierter Einblick in die RTSP-Digest-Authentifizierung – Nonce-Ablauf, Realm-Matching, stale=true-Behandlung.
401/404-Kamera-URL-Diagnose – Wenn die URL in einem Client funktioniert, in einem anderen jedoch nicht.

404 Nicht gefunden

401/404-Kamera-URL-Diagnose – Falscher Stream-Pfad, kameraspezifische URL-Formate.
Aggregate-Kontroll-URL und SDP SETUP 404 – Wenn die Kontroll-URL in SDP nicht mit der DESCRIBE-URL übereinstimmt.

454 Sitzung nicht gefunden

RTSP 454-Sitzung nicht gefunden – Sitzungs-ID stimmt nicht überein, abgelaufene Sitzungen, PLAY vor SETUP.

461 Nicht unterstützter Transport

RTSP 461 Nicht unterstützter Transport: SETUP fehlgeschlagen – UDP- vs. TCP-Transportaushandlung, ffmpeg „Methode SETUP fehlgeschlagen: 461“, Frigate/Scrypted/NVR-Integrationsfehler.

500/503 Serverfehler

RTSP 500 Internal Server Error – Kameraseitiger Fehler. Abschließend lässt sich sagen, dass die Kamera-Firmware fehlerhaft ist.
RTSP 503-Dienst nicht verfügbar – Erschöpfung der Kameraressourcen, zu viele gleichzeitige Streams, Bandbreitenbeschränkungen.

Transport und Vernetzung

UDP-RTP durch Firewall/NAT blockiert – Die RTSP-Steuerung funktioniert, aber UDP-RTP-Medien werden blockiert. Firewall-Regeln, NAT-Traversal, RTSP-Protokoll-Portkonfiguration, TCP-Interleaved-Fallback.
TCP-Interleaved-Channel-Mismatch – Wenn interleaved RTP/RTCP-Kanäle zwischen Client und Server nicht übereinstimmen.
Nicht übereinstimmende Antwort des Transportservers – Der Server antwortet mit anderen Transportparametern als angefordert.
Multicast UDP-Debugging – Multicast RTSP/RTP-Konfiguration, IGMP, TTL und Netzwerkinfrastruktur.
RTSP-Timeout: UDP vs. TCP interleaved – Warum das Stream-Timeout bei UDP vs. TCP unterschiedlich ist.

Media plane: RTP, codec, and payload problems

Control plane works perfectly — DESCRIBE returns SDP, SETUP succeeds, PLAY returns 200 OK — but video is broken. These are media plane problems.

RTP packet analysis

RTP dynamic payload type mismatch — "Unknown write" RTP/NDPI errors. How to map dynamic payload IDs to SDP rtpmap lines.
RTP packet loss diagnosis — RTP error in primary stream. Freezes, macroblocks, decoder errors. Read sequence numbers and RTCP reports to find the loss.
RTP timestamp drift — Audio/video sync loss, frame timing errors, clock rate mismatch.
RTP marker bit and frame boundaries — How the RTP marker bit signals H.264 access unit boundaries.
RTP sequence number wraparound — 16-bit sequence number rollover and how to detect actual loss vs wraparound.
RTP SSRC change mid-stream — When the camera changes SSRC mid-stream and the client loses sync.

H.264 and H.265 codec issues

H.264 FU-A fragmentation and reassembly — Missing fragments, start/end bit bugs, NAL unit reassembly failures, "invalid NAL unit" errors.
H.264 packetization mode 0 vs 1 — Single NAL vs non-interleaved mode. SDP parameter configuration.
H.264 SPS/PPS missing — Decoder errors when parameter sets are missing from SDP or RTP stream.
H.265 stream not working — H.265/HEVC failures and H.264 fallback behavior.
SDP H.264/H.265 diagnostics — Reading SDP for H.264/H.265: profile-level-id, sprop-parameter-sets, packetization-mode.

Audio and metadata tracks

Audio track AAC unknown track SDP — AAC audio tracks appearing as "unknown" in clients.

ONVIF and camera-specific

ONVIF works but RTSP URL fails — ONVIF discovery succeeds but direct RTSP connection fails.
Main stream vs sub stream — When the main stream works but the sub stream doesn't, or vice versa.

RTCP und Sitzungsverwaltung

RTCP-Absenderberichte: Jitter und Verlust – Lesen von RTCP SR-Paketen, um die Netzwerkqualität aus der Sicht der Kamera zu verstehen.
RTCP BYE: Stream endet unerwartet – Wenn die Kamera RTCP BYE sendet und den Stream beendet.
RTCP CNAME und Audio-/Video-Synchronisierung – Verwendung von RTCP CNAME zum Synchronisieren von Audio- und Videospuren.
RTSP TEARDOWN und Sitzungsbereinigung – Kameraressourcenlecks, erneute Verbindung schlägt fehl, ausgelasteter Stream-Status.
RTSP-Sitzungstimeout und Keepalive – Warum Streams nach ca. 30 Sekunden stoppen und wie man sie am Leben hält.
RTSP Range Header und NPT – Steuern der Wiedergabeposition mit Range- und NPT-Parametern.
RTSP Scale-Header und Trick Play – Schnellvorlauf, Rücklauf und Geschwindigkeitssteuerung über den Scale-Header.

Comparison and alternatives

RTSP Inspector vs Wireshark/VLC/ONVIF Device Manager — When to use a dedicated RTSP diagnostic tool vs a general network analyzer.
Wireshark RTSP alternative — Why RTSP diagnostics need more than packet capture.

Erste Schritte

Neu bei der RTSP-Diagnose? Beginnen Sie hier:

Systematischer Diagnose-Workflow – Das dreischichtige Modell und die Beweissammlung.
Mit einem Stream verbinden – Einrichten Ihrer ersten RTSP-Verbindung.
Anleitung zur Fehlerbehebung – Häufige Fehler und deren Behebung.

Reproduzierbarer Nachweis für „RTSP-Stream-Fehlerbehebung: Das vollständige Diagnosehandbuch für Kamera-Streams“

Die direkte Antwort lautet: Eine Kamerastream-Störung wird nicht durch ein einzelnes Player-Fenster oder einen Statuscode bewiesen. Die belastbare Diagnose verbindet RTSP-Anfrage und Antwort, die ausgehandelte Transportart, eine gültige Session und anschließend RTP-Sequenznummern, Zeitstempel sowie RTCP-Belege. Beginnen Sie bei „RTSP-Stream-Fehlerbehebung: Das vollständige Diagnosehandbuch für Kamera-Streams“ an der Schicht, die dem sichtbaren Symptom am nächsten liegt, behalten Sie aber eine gemeinsame Zeitleiste, damit Steuerungs-, Netzwerk- und Decoderfehler nicht vermischt werden.

Erstellen Sie vor Änderungen an Kamera, Firewall oder VMS einen kleinen Ausgangstest. Notieren Sie die bereinigte RTSP-URL, Uhrzeit, Pfad, angeforderten Transport, Serverantwort und den Zeitpunkt des ersten Medienpakets. Testen Sie UDP und TCP interleaved getrennt, sofern das Gerät beides anbietet. Ändern Sie nicht gleichzeitig Pfad, Zugangsdaten und Transport. Sonst zeigt ein erfolgreicher zweiter Versuch nicht, welche Variable den Fehler beseitigt hat.

Prüfschicht	Zu sichernder Nachweis	Entscheidungsfrage
RTSP	Methode, Status, Header, CSeq und Session	Hat der Server genau diese Operation akzeptiert?
SDP	control, Payload-Typ, Clock Rate und Codec	Beschreibt der Server den erwarteten Medientrack?
Transport	client_port, server_port oder interleaved	Verwenden beide Seiten denselben Kanal?
RTP	SSRC, Sequenz, Timestamp und Marker	Kommen Medieneinheiten in erklärbarer Reihenfolge an?
RTCP	Sender Report, CNAME und BYE	Sind Uhr, Identität und Sitzungsende nachvollziehbar?
Decoder	SPS/PPS/VPS und Packetization Mode	Lassen sich die angekommenen Nutzdaten initialisieren?

Trennen Sie „keine Medien angekommen“ von „Medien angekommen, aber nicht decodierbar“. Fehlt RTP nach erfolgreichem SETUP und PLAY, prüfen Sie UDP-Pfad, NAT, Firewall und einen abweichenden Transport-Reply. RTP mit Sequenzlücken belegt Verlust oder Reordering. Eine lückenlose Folge ohne Bild verschiebt die Prüfung auf Payload-Typ, Clock Rate, Frame-Grenzen und H.264-/H.265-Parameter. Diese Grenze ist aussagekräftiger als eine allgemeine Player-Meldung.

Wie formuliert man eine zitierfähige Kurzantwort?

Nennen Sie in drei Sätzen die letzte erfolgreiche Operation, den ersten fehlgeschlagenen Beleg und den nächsten trennenden Test. Beispielstruktur: „DESCRIBE, SETUP und PLAY waren erfolgreich. An den angekündigten Client-Ports kam kein RTP an. Ein Test über TCP interleaved trennt UDP-Blockierung von einem falschen Medienpfad.“ Behaupten Sie keinen Kamera- oder Netzwerkdefekt ohne passende Antwort oder Paketbeleg.

Welche Angaben machen den Fehler reproduzierbar?

Sichern Sie OPTIONS, DESCRIBE, SETUP und PLAY samt SDP, Transport-Antwort und bereinigter Session-ID. Für Medien genügen zunächst SSRC, erste und letzte Sequenznummer, Clock Rate, Lückenanzahl und Aufnahmedauer. Vermerken Sie, ob VLC oder ein anderes VMS funktioniert. Das ist ein Differenztest, aber kein Beweis, dass der erfolgreiche Client jede Protokollgrenze korrekt behandelt.

Wann liegt der nächste Test auf Server- oder Clientseite?

Prüfen Sie den Server, wenn er eine Methode klar ablehnt, einen nicht vorhandenen control-Pfad liefert, das Transportangebot widersprüchlich beantwortet oder SSRC beziehungsweise Clock Rate ohne erklärten Übergang wechselt. Prüfen Sie den Client, wenn er einen alten Nonce wiederverwendet, Session-Header verliert, UDP anfordert ohne Ports zu öffnen oder jedes NAL-Ende als Access-Unit-Ende behandelt. Für Zwischenfehler bleiben Zeitstempel und Paketfolge unverzichtbar.

Wie wird der Bericht vor der Übergabe geprüft?

Wiederholen Sie den Test mit einer frischen Verbindung und vergleichen Sie beide Abläufe nur bis zur ersten Abweichung. Entfernen Sie Passwörter und vollständige Authorization-Werte. Verknüpfen Sie jede Aussage mit CSeq, Sequenznummer oder Timestamp. Der passende RTSP-Leitfaden erklärt angrenzende Schritte; RTSP Inspector dient als lokaler Arbeitsbereich zum Testen eines RTSP-Streams und zum Sammeln der Belege, ohne den Kamerastream zu einem öffentlichen Dienst hochzuladen.

Direkte Antwort und Abnahmegrenze

Die kurze Antwort zu „RTSP-Stream-Fehlerbehebung: Das vollständige Diagnosehandbuch für Kamera-Streams“ lautet: Vollständiger RTSP-Diagnose-Workflow: Verbindungsschicht, Fehler der Steuerebene (400/401/404/454/461/500/503), Ausfälle der Medienebene (H.264/H.265/RTP/RTCP), Sitzungsverwaltung und Vergleich mit Wireshark/VLC. Jedes RTSP-Problem wird einer Diagnoseseite zugeordnet. 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: RTSP-Stream-Fehlerbehebung: Das vollständige Diagnosehandbuch für Kamera-Streams

Prüfen Sie „RTSP-Stream-Fehlerbehebung: Das vollständige Diagnosehandbuch für Kamera-Streams“ 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 2: Vollständiger RTSP-Diagnose-Workflow: Verbindungsschicht, Fehler der Steuerebene (400/401/

Ist „Vollständiger RTSP-Diagnose-Workflow: Verbindungsschicht, Fehler der Steuerebene (400/401/404/454/461/500/503), Ausfälle der Medienebene (H.264/H.265/“ 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 3: Steuerungsebene: RTSP-Befehlsfehler

Prüfen Sie „Steuerungsebene: RTSP-Befehlsfehler“ 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 4: 400 Ungültige Anfrage

Ist „400 Ungültige Anfrage“ 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 5: 401 Nicht autorisiert

Prüfen Sie „401 Nicht autorisiert“ 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 6: 404 Nicht gefunden

Ist „404 Nicht gefunden“ 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 7: 454 Sitzung nicht gefunden

Prüfen Sie „454 Sitzung nicht gefunden“ 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 8: 461 Nicht unterstützter Transport

Ist „461 Nicht unterstützter Transport“ 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 9: 500/503 Serverfehler

Prüfen Sie „500/503 Serverfehler“ 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 10: Transport und Vernetzung

Ist „Transport und Vernetzung“ 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.

Abnahmematrix

Prüfpunkt	Aufzubewahrender Nachweis	Passkriterium
RTSP-Stream-Fehlerbehebung: Das vollständige Diagnosehandbuch für Kamera-Streams	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Vollständiger RTSP-Diagnose-Workflow: Verbindungsschicht, Fehler der Steuerebene (400/401/404/454/461/500/503), Ausfälle	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Steuerungsebene: RTSP-Befehlsfehler	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
400 Ungültige Anfrage	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
401 Nicht autorisiert	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
404 Nicht gefunden	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.