RTSP stellt eine Verbindung her, zeigt aber kein Video: Was Sie überprüfen sollten, bevor Sie dem Player die Schuld geben

Eines der häufigsten Kamera-Support-Tickets klingt einfach: "Die RTSP-URL stellt eine Verbindung her, die Authentifizierung ist erfolgreich, aber dem Betrachter wird kein Video angezeigt. Der natürliche Instinkt besteht darin, einen anderen Spieler auszuprobieren. Das kann nützlich sein, beantwortet aber nicht die technische Frage: Ist der Stream bei der RTSP-Steuerung, der SDP-Aushandlung, der RTP-Zustellung oder der Codec-Bereitschaft fehlgeschlagen?" Für CCTV-Integratoren, VMS-Ingenieure und Kameraverkäufer ist diese Unterscheidung wichtig. Ein Spieler kann Paketverluste verbergen, den alten Decoderstatus wiederverwenden oder stillschweigend Transportmodi erneut ausprobieren. Ein Diagnosebericht sollte erklären, welcher Teil des Streams sich als fehlerfrei erwiesen hat und welcher nicht.

Trennen Sie Kontrollerfolg vom Medienerfolg

RTSP ist ein Kontrollprotokoll. Eine erfolgreiche Sequenz „DESCRIBE“, „SETUP“ und „PLAY“ beweist, dass die Kamera die Sitzung akzeptiert hat. Es beweist nicht, dass RTP-Pakete angekommen sind. Es beweist auch nicht, dass es sich bei der Nutzlast tatsächlich um H.264 oder H.265 in der von SDP angekündigten Form handelt.

Eine nützliche Aufzeichnung für den ersten Durchgang:

• die RTSP-Statuscodes für „OPTIONS“, „DESCRIBE“, „SETUP“ und „PLAY“.
• ob der SDP-Körper einen Videomedienabschnitt enthält
• der für die Videospur ausgehandelte Nutzlasttyp
• ob RTP-Pakete nach „PLAY“ ankommen
• ob der RTP-Zeitstempel und die Sequenznummern vorwärts verschoben werden
• ob die erste Videonutzlast Codec-Parameternachweise enthält

Wenn die Steuerung erfolgreich ist, aber kein RTP ankommt, liegt das Problem normalerweise an Transport, Firewall, NAT, Kameramodus oder serverseitiger Stream-Verfügbarkeit. Wenn RTP ankommt, aber kein dekodierbares Video vorhanden ist, verlagert sich das Problem in Richtung Nutzlast, Paketierung oder Codec-Metadaten.

Warum SDP die erste Evidenzgrenze ist

SDP teilt dem Client mit, was die Kamera angeblich senden wird. Für H.264 suchen Ingenieure nach „rtpmap“- und „fmtp“-Werten wie Paketierungsmodus, Profilebenen-ID und „sprop-parameter-sets“. Bei H.265 überträgt das SDP VPS-, SPS- und PPS-Informationen möglicherweise unterschiedlich und viele Verbraucher haben strengere Unterstützungsgrenzen.

Wenn das SDP H.264 anzeigt, die Medienbytes jedoch nicht die erwartete NAL-Einheitenstruktur enthalten, handelt es sich bei dem Fehler nicht um ein allgemeines „Player-Problem“. Es besteht ein Missverhältnis zwischen beworbenen Metadaten und der Realität der Nutzdaten. Wenn SDP Parametersätze weglässt und der RTP-Stream sie nie bandintern sendet, kann ein Decoder ewig warten.

Aus diesem Grund sollte ein RTSP-Inspektionsworkflow SDP neben den Medienbeweisen aufbewahren und nicht in einem Spielerprotokoll vergraben.

RTP-Ankunft reicht nicht aus

Selbst wenn RTP-Pakete ankommen, kann es dennoch zu Fehlern beim Video kommen. H.264- und H.265-Frames hängen häufig von früheren Paketen ab. Ein fehlendes Paket kann dazu führen, dass das nächste Slice nicht mehr kodiert werden kann. Eine Lieferung außerhalb der Reihenfolge kann wie Korruption aussehen. Eine Nutzlast, die mitten in der GOP startet, ist möglicherweise erst dann für die Dekodierung bereit, wenn das nächste Schlüsselbild und der nächste Parametersatz erscheint.

Die zu sammelnden Mindestnachweise sind:

• Kontinuität der RTP-Sequenz
• Zeitstempelverlauf
• Verhalten des Markierungsbits
• Konsistenz des Nutzlasttyps
• H.264- oder H.265-NAL-Einheitenkategorien
• SPS, PPS und für H.265 VPS-Sichtbarkeit
• Erste Keyframe-Bereitschaft

Dies erklärt, warum sowohl „VLC spielt es ab“ als auch „unsere Analysepipeline lehnt es ab“ wahr sein können. Einige Zuschauer erholen sich aggressiv. Technische Systeme benötigen häufig normenreine Nachweise.

TCP versus UDP ist eine diagnostische Wahl

Die Umstellung des RTSP-Transports von UDP auf TCP ist ein häufiger Schritt zur Fehlerbehebung, sollte aber nicht als Allheilmittel betrachtet werden. TCP-Interleaving kann blockierte UDP-Ports vermeiden und durch Netzwerkrichtlinien verursachte Paketverluste reduzieren. Es kann auch verbergen, ob der vorgesehene UDP-Pfad der Bereitstellung funktioniert.

Ein guter Erfahrungsbericht dokumentiert beide Versuche:

• RTSP über TCP interleaved: Kommt das Medium an?
• RTP über UDP Unicast: Kommen Pakete auf den ausgehandelten Ports an?
• RTCP: Zeigt das Feedback des Absenders Timing und Paketanzahl an?

Wenn TCP funktioniert und UDP fehlschlägt, ist die Antwort wahrscheinlich keine Codec-Unterstützung. Es handelt sich wahrscheinlich um Netzwerkpfad, Firewall, NAT oder Portzuweisung. Wenn beide Transporte RTP liefern, die Dekodierung jedoch immer noch fehlschlägt, überprüfen Sie die Codec-Struktur.

Wo RTSP Inspector passt

RTSP Inspector wurde genau für diese Grenze entwickelt. Es geht nicht darum, ein Videoplayer oder NVR zu werden. Es erfasst die Beweise rund um die RTSP-Sitzung, SDP, RTP/RTCP-Fluss und H.264/H.265-Bereitschaft, sodass ein Ingenieur erklären kann, warum „verbunden“ nicht zu „verwendbarem Video“ wurde.

Die nützliche Ausgabe ist kein Screenshot eines schwarzen Player-Fensters. Es ist eine wiederholbare Antwort:

• Die RTSP-Steuerung war erfolgreich
• SDP hat diesen Codec und Nutzlasttyp angekündigt
• RTP ist angekommen oder nicht angekommen
• Die Paketsequenz war kontinuierlich oder unterbrochen
• Hinweise auf Codec-Parameter waren vorhanden oder fehlten
• Die nächste Aktion gehört zu Netzwerk, Kamerakonfiguration, Firmware oder Stream-Consumer

Das ist der Unterschied zwischen dem Ansehen eines Streams und der Diagnose eines Streams.