SDP, H.264 und H.265 in der RTSP-Diagnose: Die Metadaten, die darüber entscheiden, ob Videos gestartet werden können

Viele RTSP-Fehler werden als „Der Kamerastream wird nicht abgespielt“ beschrieben. Dieser Satz verbirgt die wichtigste diagnostische Grenze: "Was hat die Kamera in SDP behauptet und stimmte die Mediennutzlast mit dieser Behauptung überein?" SDP ist oft der erste strukturierte Beweis, der in einer RTSP-Sitzung verfügbar ist. Es deklariert Medienspuren, Nutzlasttypen, Codec-Namen, Taktraten, Steuer-URLs und Codec-spezifische Parameter. Wenn das SDP falsch, unvollständig oder vom Verbraucher nicht unterstützt wird, kann ein Stream fehlschlagen, bevor der erste Frame dekodiert ist.

Was SDP beweisen sollte

Nach „DESCRIBE“ sollte ein Client wissen, ob der Stream Video enthält, welcher Payload-Typ welchem ​​Codec zugeordnet ist und wie die Medienspur eingerichtet werden soll. Überprüfen Sie zur Kameradiagnose Folgendes:

• Medienbereich „m=video“.
• „a=control“-Track-URL
• „a=rtpmap“-Nutzlasttyp und Codec-Name
• „a=fmtp“-Codec-Parameter
• H.264 „sprop-parameter-sets“, sofern vorhanden
• H.265 VPS/SPS/PPS-Signalisierung, sofern verfügbar
• ob die angekündigte Taktrate erwartet wird

Wenn SDP H.264 ankündigt, die Kamera aber etwas anderes sendet, ist der Empfänger nicht unvernünftig. Wenn SDP wichtige Parameternachweise auslässt und der Stream sie nie bandintern sendet, verfügt der Decoder möglicherweise nicht über genügend Informationen, um zu beginnen.

H.264-Parametersätze sind kein optionaler Beweis

H.264-Decoder benötigen Sequenz- und Bildparameterinformationen. Bei RTSP-Kamerabereitstellungen können diese Beweise in SDP, In-Band-RTP-Nutzlasten oder beidem erscheinen. Probleme treten auf, wenn eine Kamera davon ausgeht, dass der Empfänger bereits etwas weiß, was er nicht weiß.

Eine saubere Diagnoseaufzeichnung antwortet:

• war SPS sichtbar?
• war PPS sichtbar?
• Enthielten die Nutzlasten einen IDR-Frame?
• Hat der Stream mitten in der GOP begonnen?
• Sah die ID auf Profilebene plausibel aus?
• Entsprach der Paketierungsmodus der beobachteten Nutzlaststruktur?

Dies ist besonders wichtig, wenn ein Spieler arbeitet und ein anderer nicht. Ein toleranter Betrachter kann fragwürdige Metadaten überleben. Eine Aufzeichnungs-, Analyse- oder Compliance-Pipeline kann es ablehnen.

H.265 fügt weitere Kompatibilitätsgrenzen hinzu

H.265 ist bei modernen Kameras weit verbreitet, insbesondere wenn es auf die Bandbreite ankommt, wird jedoch bei älteren Geräten und eingebetteten Verbrauchern weniger allgemein unterstützt als H.264. H.265 bietet neben SPS und PPS auch VPS-Beweise. Eine Bereitstellung, die nur „RTSP funktioniert“ sagt, kann dennoch fehlschlagen, weil das tatsächliche Codec-Profil oder die Parameterbereitstellung außerhalb der vom Verbraucher unterstützten Grenzen liegt.

Für Außendienstteams sollte in einem nützlichen Artikel, Ticket oder Bericht nicht nur „Wechsel zu H.264“ stehen. Es sollte erklären, warum:

• Dem aktuellen Verbraucher fehlt die H.265-Unterstützung
• Die H.265-Parametersätze fehlen oder sind spät
• Der Nutzlasttyp stimmt nicht mit der erwarteten Codec-Zuordnung überein
• Der Stream ist gültig, liegt jedoch außerhalb der Produktgrenze
• Für diesen Workflow sollte das Kameraprofil geändert werden

Dieses Maß an Klarheit verhindert wiederholte Änderungen durch Versuch und Irrtum.

SDP muss mit RTP verglichen werden

SDP ist eine Behauptung. RTP ist der folgende Beweis. Die beiden müssen verglichen werden.

Beispiele:

• SDP behauptet, der Nutzlasttyp 96 sei H.264, RTP kommt jedoch mit einem anderen Nutzlasttyp an.
• SDP enthält eine Videospur, aber auf „PLAY“ folgt kein RTP.
• SDP sagt H.265, aber das Downstream-Produkt unterstützt nur H.264.
• SDP lässt Parametersätze weg und RTP sendet sie nie vor Slices.
• RTP kommt an, aber die NAL-Einheitsstruktur stimmt nicht mit dem angekündigten Codec überein.

Diese Fälle erfordern unterschiedliche nächste Maßnahmen. Ohne einen Vergleich von SDP und RTP sehen alle wie der gleiche vage „Kein Video“-Fehler aus.

Warum RTSP Inspector diese Beweise ans Licht bringt

RTSP Inspector wurde für Stream-Ingenieure, Kameraverkäufer und CCTV-Integratoren entwickelt, die wiederholbare Beweise benötigen. Es handelt sich bewusst nicht um einen generischen Mediaplayer. Seine Aufgabe besteht darin, den RTSP-Kontrollpfad, die SDP-Metadaten, den RTP/RTCP-Fluss und die H.264/H.265-Bereitschaft zu überprüfen.

Dadurch ist die Ausgabe in Supportgesprächen nützlich:

• Kamerahersteller: SDP oder Paketierung korrigieren
• Netzwerkteam: RTP-Zustellungspfad korrigieren
• VMS-Team: Unterstütztes Codec-Profil anpassen
• Feldintegrator: Stromprofil oder Transportmodus ändern
• Kunde: Verstehen Sie, warum die Wiedergabe kein Beweis für die Integrität des Protokolls ist

In der RTSP-Diagnose ist SDP kein Boilerplate-Text. Es ist der erste Vertrag, den der Stream anbietet. Wenn dieser Vertrag gebrochen wird, rätselt der Rest der Pipeline.