RTCP-Absenderberichte, Jitter und Paketverlust: Stream-Zustand lesen, ohne Videos anzusehen

Wenn Ingenieure nach „RTSP-Jitter“, „RTP-Paketverlust“ oder „RTCP-Absenderbericht“ suchen, versuchen sie normalerweise, eine praktische Frage zu beantworten: "Ist der Stream fehlerhaft oder hat der Player nur Probleme? Die Videowiedergabe ist ein Spätsymptom. RTP- und RTCP-Beweise erscheinen früher und sind in einem Supportfall leichter zu verteidigen." RTCP ist der Kontrollbegleiter von RTP. Es kann Senderberichte, Empfängerberichte, Paketzahlen, Zeitinformationen und Qualitätsfeedback übertragen. Nicht jede Kamera weist umfangreiches RTCP-Verhalten auf und nicht jede Bereitstellung leitet es korrekt weiter, aber wenn RTCP vorhanden ist, liefert es wichtigen Kontext, den die Raw-Wiedergabe nicht bietet.

Warum RTCP bei der Kameradiagnose wichtig ist

RTP überträgt Medienpakete. RTCP hilft bei der Beschreibung des Zustands von Mediensitzungen. Bei einem RTSP-Kamerastream können RTCP-Beweise helfen, Folgendes zu beantworten:

• Ist der Absender nach „PLAY“ noch am Leben?
• Wie viele RTP-Pakete hat der Absender gemeldet?
• Sind RTP-Zeitstempel auf das Zeitverhalten der Wanduhr abgestimmt?
• Ist die Paketzustellung gleichmäßig oder stoßweise?
• Ist Jitter sichtbar?
• Wurde RTP fortgesetzt, während die Videodekodierung fehlschlug?
• Enthält der Medienpfad überhaupt RTCP?

Wenn die RTSP-Steuerung erfolgreich ist und RTP eintrifft, das Video jedoch einfriert, kann RTCP dabei helfen, das Netzwerk-Timing von der Codec-Bereitschaft zu trennen.

Absenderberichte sind Zeitbeweise

Ein RTCP-Absenderbericht kann einen RTP-Zeitstempel mit einem absoluten Zeitwert im NTP-Stil in Beziehung setzen. Diese Beziehung hilft Empfängern, Streams zu synchronisieren und das Uhrverhalten zu ermitteln. In der Diagnostik ist die genaue Mathematik möglicherweise weniger wichtig als die Existenz und Konsistenz der Berichte.

Nützliche Beobachtungen:

• Der Absenderbericht wird angezeigt, nachdem die Medien gestartet wurden
• Die Anzahl der Pakete und Oktette nimmt zu
• Die RTP-Zeitstempelzuordnung ist konsistent
• Berichtsintervall ist plausibel
• Berichte werden gestoppt, wenn RTP stoppt
• Die Meldungen werden auch dann fortgesetzt, wenn der Decoder ausfällt

Wenn RTCP zusammen mit RTP stoppt, kann es zu einer Unterbrechung des Absender- oder Medienpfads kommen. Wenn RTCP fortgesetzt wird, die Videodekodierung jedoch fehlschlägt, überprüfen Sie die Nutzlast und den Codec-Beweis.

Jitter ist nicht dasselbe wie Paketverlust

Jitter bedeutet, dass Pakete mit unterschiedlichem Timing ankommen. Paketverlust bedeutet, dass Pakete fehlen. Beides kann zu sichtbarem Stottern führen, führt jedoch zu unterschiedlichen Lösungen.

RTP-Sequenznummern zeigen fehlende Pakete an. RTP-Zeitstempel und Ankunftszeiten zeigen zeitliche Abweichungen. RTCP-Berichte können Feedback auf Sitzungsebene hinzufügen. In einem ordnungsgemäßen Bericht sollte nicht nur „schlechtes Netzwerk“ stehen. Es sollte angegeben werden, ob das Problem Verlust, Jitter, Burst-Zustellung, blockiertes RTCP oder Codec-Dekodierungsgrenze ist.

Bei Kameras kann Jitter folgende Ursachen haben:

• Wi-Fi-Uplink-Variante
• Überlasteter Kamera-Encoder
• NVR-Weiterleitungsverzögerung
• überlasteter Weichenweg
• VPN- oder WAN-Pfad
• clientseitiges Pufferverhalten

Paketverlust kann folgende Ursachen haben:

• UDP fällt
• Firewall-/NAT-Verhalten
• überlastetes Netzwerk
• Kamera-Sendepufferdruck
• Beschränkungen der Eroberungspunkte

Die Korrekturen sind unterschiedlich.

Das Fehlen von RTCP ist ebenfalls ein Beweis

Einige Bereitstellungen blockieren RTCP, selbst wenn RTP fließt. Einige Kameras senden kein nützliches RTCP. Manche Kunden fordern oder erhalten es nie deutlich. Fehlendes RTCP bedeutet nicht automatisch, dass der Stream unterbrochen ist, es sollte jedoch aufgezeichnet werden.

Wenn RTP über UDP ausgehandelt wird, prüfen Sie beide Medien und kontrollieren Sie den Companion-Verkehr. Wenn RTSP über TCP Interleaved verwendet wird, überprüfen Sie die Metadaten des Interleaved-Kanals. Ein Bericht mit der Meldung „RTP sichtbar, RTCP nicht vorhanden“ ist nützlicher als ein leeres Feld.

Wo RTSP Inspector passt

RTSP Inspector dient der Protokollbeweisführung und nicht der passiven Betrachtung. RTCP gehört in dieselbe Geschichte wie RTSP-Methoden, SDP, RTP-Sequenzkontinuität, Nutzlasttyp, Codec-Metadaten und Berichtsexport.

Bei RTCP-intensiven Suchen sollte RTSP Inspector bei der Beantwortung helfen:

• Kam RTP nach „PLAY“ an?
• Sind RTCP-Absenderberichte erschienen?
• Ist die Paketanzahl gestiegen?
• Waren Jitter oder Sequenzlücken mit sichtbaren Fehlern verbunden?
• Ist die Codec-Bereitschaft trotz Medienbereitstellung fehlgeschlagen?
• Hat der Transportmodus das Gesundheitsprofil verändert?

Das gibt einem Kamerahersteller, Netzwerktechniker oder VMS-Entwickler einen konkreten Ausgangspunkt. „Der Stream stottert“ ist ein Symptom. „RTP-Sequenzlücken und Jitter nahmen nach PLAY zu, während die RTSP-Kontrolle aktiv blieb“, ist ein Beweis dafür.