2026-06-02

RTSP-Hauptstream funktioniert nicht, aber Substream funktioniert: Was der Unterschied beweist

Eine Diagnoseanleitung für IP-Kamerafälle, bei denen der RTSP-Substream funktioniert, der Hauptstream jedoch ausfällt, einfriert, 404 zurückgibt oder nicht dekodiert werden kann.

Eine sehr häufige Suchanfrage nach IP-Kameras lautet: "„RTSP-Hauptstream funktioniert nicht, aber Substream funktioniert.“ Das Symptom ist spezifisch genug, um nützlich zu sein. Wenn der Substream funktioniert, ist die Kamera erreichbar, die Anmeldeinformationen sind wahrscheinlich korrekt, der RTSP-Dienst ist aktiviert und auf mindestens ein Videoprofil kann zugegriffen werden. Das Problem ist nicht mehr „RTSP ist kaputt“. Das Problem ist der Unterschied zwischen Stream-Profilen." Haupt- und Substream unterscheiden sich normalerweise in Auflösung, Bitrate, Codec, GOP-Intervall, Nutzlastgröße und manchmal sogar im URL-Pfad. Ein Substream kann H.264 mit niedriger Auflösung sein, während der Hauptstream H.265, 4K, hohe Bitrate oder auf weniger gleichzeitige Sitzungen beschränkt ist. Ein NVR kann verschiedene Pfade von der Kamera selbst aus anzeigen. ONVIF gibt möglicherweise eine Live-URL von geringer Qualität zurück, während die Aufzeichnungs-URL oder das Hauptprofil einen separaten Pfad erfordert.

Die nützliche Diagnosefrage lautet: Was beweist der funktionierende Teilstrom und was beweist er nicht?

Was ein funktionierender Substream beweist

Wenn der Substream über RTSP geöffnet werden kann, können Sie normalerweise sagen:

Die IP-Adresse der Kamera ist erreichbar
Der RTSP-Port ist offen
Die Authentifizierung funktioniert für mindestens einen Stream
Der Client kann grundlegende RTSP-Antworten analysieren
„DESCRIBE“, „SETUP“ und „PLAY“ können für mindestens ein Profil erfolgreich sein
Für mindestens einen Medientitel ist eine RTP-Auslieferung möglich

Das ist ein wertvoller Beweis. Es schränkt die Suche ein. Nach diesem Zeitpunkt sollten Sie die grundlegende Netzwerkerreichbarkeit nicht weiter debuggen, es sei denn, der Hauptstream verwendet einen anderen Host, Port, Transportmodus oder NVR-Pfad.

Was ein funktionierender Substream nicht beweist

Ein funktionierender Substream beweist nicht:

Der URL-Pfad des Hauptstreams ist korrekt
Der Hauptstream ist aktiviert
Der Mainstream-Codec wird unterstützt
Die Bitrate des Hauptstroms kann das Netzwerk durchqueren
Der Hauptstream steht mehreren Clients zur Verfügung
Der Hauptstrom sendet dekodierbereite SPS/PPS- oder VPS/SPS/PPS-Beweise
Der NVR stellt den Hauptstrom der Kamera über denselben Pfad bereit

Aus diesem Grund reicht „VLC kann den Substream öffnen“ für ein VMS, ein Analysesystem oder eine Restreaming-Pipeline, die den Hauptstream benötigt, nicht aus.

Überprüfen Sie den URL-Pfad vor dem Codec

Viele Kamerafamilien verwenden unterschiedliche Pfadmuster für Haupt- und Unterströme. Einige verwenden „Profil1“ und „Profil2“. Einige verwenden „/Streaming/Channels/101“ und „/Streaming/Channels/102“. Einige verwenden „main“, „sub“, „video1“, „video2“ oder herstellerspezifische Zugriffsnamen. Einige NVRs stellen Kanäle anders dar als direkte Kamera-URLs.

Wenn der Hauptstream „404 Not Found“ zurückgibt, überprüfen Sie Folgendes:

Genauer Anfrage-URI, der in „DESCRIBE“ gesendet wurde
ob der URL-Pfad mit dem Anbietermodell übereinstimmt
Kanalnummer
Stream-Nummer
Von ONVIF entdecktes Profil-Token
ob der Stream in der Web-Benutzeroberfläche der Kamera aktiviert ist
ob die URL auf die Kamera-IP oder die NVR-IP abzielt

Behandeln Sie einen 404-Fehler nicht als Paketverlust. RTP wurde noch nicht gestartet.

Überprüfen Sie Codec und Bitrate, nachdem der Pfad gültig ist

Wenn der Hauptstream SDP zurückgibt und RTP startet, aber immer noch kein Video anzeigt, wechseln Sie zu Codec und Mediennachweis.

Mainstream-Ausfälle sind häufig auf folgende Ursachen zurückzuführen:

H.265 ausgewählt, während der Verbraucher H.264 erwartet
fehlende H.264 SPS/PPS- oder H.265 VPS/SPS/PPS-Beweise
sehr langes Keyframe-Intervall
hoher Bitratenverlust über WLAN oder schwacher Uplink
Paketfragmentierung und -verlust unter Bewegung
Decoder-Profil oder -Level wird vom Downstream-System nicht unterstützt

Zu diesem Zeitpunkt sollte der Bericht SDP, Nutzlasttyp, RTP-Sequenzkontinuität, Codec-NAL-Einheitsnachweise und ob die erste Decodierungsgrenze erreicht wurde, enthalten.

Parallelitätsgrenzen und NVR-Verhalten

Einige preisgünstige DVRs, NVRs oder Kamera-Firmware-Versionen schränken den Hauptstream-Zugriff ein. Der Unterstream bleibt möglicherweise verfügbar, während der Hauptstream bereits von der lokalen Anzeige, Aufzeichnung, der Anbieter-App oder einem anderen Client genutzt wird. Dies kann wie ein URL-Problem aussehen, selbst wenn der Pfad korrekt ist.

Nützliche Kontrollen:

Andere Zuschauer trennen
Testen Sie die direkte Kamera-IP im Vergleich zur NVR-IP
Vergleichen Sie den Hauptstream der Web-Benutzeroberfläche der Kamera
niedrigere Mainstream-Bitrate oder Auflösung
Wechseln Sie den Hauptstream-Codec von H.265 zu H.264
Testen Sie RTSP über TCP interleaved und UDP separat

Wenn das Problem durch eine Verringerung der Bitrate behoben wird, liegt der ursprüngliche Fehler möglicherweise eher an der Transportkapazität als an der URL-Syntax.

Wie RTSP Inspector diesen Fall darstellen sollte

Der RTSP-Inspektor ist am stärksten, wenn er die Grenze erklärt:

Der Substream-Steuerungspfad ist erfolgreich
Der Hauptstrom-Kontrollpfad schlägt mit Statuscode fehl
Der Hauptstream gibt SDP zurück, aber kein RTP
Der Mainstream-RTP kommt mit Paketverlust an
Die Metadaten des Hauptstream-Codecs fehlen oder werden nicht unterstützt
Der Hauptstrom ist H.265, während Verbraucher H.264 benötigen

Das ist der Unterschied zwischen „Mainstream kaputt“ und einem nützlichen Supportbericht. Die richtige nächste Aktion könnte die Suche nach Anbieter-URLs, die Konfiguration des Stream-Profils, die Änderung des Codecs, die Reduzierung der Bitrate, die Aktualisierung der Firmware oder die Reparatur des Netzwerkpfads sein.

Wenn Ihre genaue Suche „RTSP-Substream funktioniert, Hauptstream funktioniert jedoch nicht“ lautet, vergleichen Sie zunächst RTSP-Methoden, SDP, Codec, Transport und Parallelität. Der Arbeitsunterstrom ist nicht das Ende der Diagnose. Es handelt sich um die Kontrollprobe.

Reproduzierbarer Nachweis für „RTSP-Hauptstream funktioniert nicht, aber Substream funktioniert: Was der Unterschied beweist“

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-Hauptstream funktioniert nicht, aber Substream funktioniert: Was der Unterschied beweist“ 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-Hauptstream funktioniert nicht, aber Substream funktioniert: Was der Unterschied beweist“ lautet: Eine Diagnoseanleitung für IP-Kamerafälle, bei denen der RTSP-Substream funktioniert, der Hauptstream jedoch ausfällt, einfriert, 404 zurückgibt oder nicht dekodiert werden kann. 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-Hauptstream funktioniert nicht, aber Substream funktioniert: Was der Unterschied bewe

Ist „RTSP-Hauptstream funktioniert nicht, aber Substream funktioniert: Was der Unterschied beweist“ 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 2: Eine Diagnoseanleitung für IP-Kamerafälle, bei denen der RTSP-Substream funktioniert, der

Prüfen Sie „Eine Diagnoseanleitung für IP-Kamerafälle, bei denen der RTSP-Substream funktioniert, der Hauptstream jedoch ausfällt, einfriert, 404 zurückgibt oder “ 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: Was ein funktionierender Substream beweist

Ist „Was ein funktionierender Substream beweist“ 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 4: Was ein funktionierender Substream nicht beweist

Prüfen Sie „Was ein funktionierender Substream nicht beweist“ 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 5: Überprüfen Sie den URL-Pfad vor dem Codec

Ist „Überprüfen Sie den URL-Pfad vor dem Codec“ 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: Überprüfen Sie Codec und Bitrate, nachdem der Pfad gültig ist

Prüfen Sie „Überprüfen Sie Codec und Bitrate, nachdem der Pfad gültig ist“ 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 7: Parallelitätsgrenzen und NVR-Verhalten

Ist „Parallelitätsgrenzen und NVR-Verhalten“ 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 8: Wie RTSP Inspector diesen Fall darstellen sollte

Prüfen Sie „Wie RTSP Inspector diesen Fall darstellen sollte“ 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: Reproduzierbarer Nachweis für „RTSP-Hauptstream funktioniert nicht, aber Substream funktio

Ist „Reproduzierbarer Nachweis für „RTSP-Hauptstream funktioniert nicht, aber Substream funktioniert: Was der Unterschied beweist““ 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 10: Wie formuliert man eine zitierfähige Kurzantwort?

Prüfen Sie „Wie formuliert man eine zitierfähige Kurzantwort?“ 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.

Abnahmematrix

Prüfpunkt	Aufzubewahrender Nachweis	Passkriterium
RTSP-Hauptstream funktioniert nicht, aber Substream funktioniert: Was der Unterschied beweist	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Eine Diagnoseanleitung für IP-Kamerafälle, bei denen der RTSP-Substream funktioniert, der Hauptstream jedoch ausfällt, e	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Was ein funktionierender Substream beweist	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Was ein funktionierender Substream nicht beweist	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Überprüfen Sie den URL-Pfad vor dem Codec	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Überprüfen Sie Codec und Bitrate, nachdem der Pfad gültig ist	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.