Fehlendes H.264 SPS/PPS in RTSP-Streams: Warum VLC abspielt, aber FFmpeg oder Analytics fehlschlägt

Ein frustrierendes RTSP-Fehlermuster ist Kameraingenieuren bekannt: "VLC spielt den Stream ab, aber FFmpeg, ein VMS, eine Analysepipeline oder ein Cloud-Ingest-Dienst schlagen mit Decoderfehlern fehl. Der Support-Thread wird oft zu einer Debatte darüber, welches Tool das „richtige“ ist. Die bessere Frage ist, ob der Stream genügend H.264-Parameternachweise für einen neuen Decoder liefert." H.264 benötigt Sequenzparametersätze und Bildparametersätze. Ingenieure nennen sie normalerweise SPS und PPS. Sie beschreiben, wie der Bitstrom dekodiert werden soll: "Profil, Ebene, Abmessungen, Referenzverhalten und Bildstruktur. Ohne sie sieht ein Decoder möglicherweise Slice-Daten, hat aber immer noch keinen gültigen Kontext, um sie in Frames umzuwandeln."

Wo SPS und PPS auftreten können

In RTSP-Bereitstellungen können SPS/PPS-Beweise an mehr als einer Stelle erscheinen:

• SDP „sprop-parameter-sets“.
• In-Band-RTP-Nutzlasten vor Slices
• vor Schlüsselbildern wiederholt
• von einem toleranten Spieler aus einer früheren Sitzung zwischengespeichert
• Lieferung erst nach Warten auf den nächsten IDR

Dies erklärt das Problem „Funktioniert in einem Viewer“. Ein Spieler kann den Status wiederverwenden, länger warten, fehlende Referenzen wiederherstellen oder eine Fehlerverdeckung anwenden. Ein strikter Ingest-Dienst beginnt möglicherweise mit einem leeren Decoder und lehnt den Stream ab, bis SPS/PPS und ein verwendbarer Schlüsselrahmen eintreffen.

Was der Fehler tatsächlich bedeutet

Meldungen wie „Fehlendes Bild in der Zugriffseinheit“, „Dekodierungs-Slice-Header-Fehler“, „Nicht vorhandenes PPS referenziert“ oder „Warten auf SPS/PPS“ bedeuten nicht automatisch, dass die Kamera defekt ist. Dies bedeutet, dass der Decoder zum Zeitpunkt des Decodierungsversuchs nicht über den Parameterkontext verfügte, den er benötigte.

Die diagnostischen Fragen sind:

• Enthält SDP „sprop-parameter-sets“?
• Wurden SPS und PPS in der RTP-Nutzlast gesehen?
• Sind sie vor dem ersten Stück angekommen?
• Ist nach Parametersätzen ein IDR-Frame erschienen?
• Hat der Paketverlust das Parametersatzpaket entfernt?
• Hat der Stream mitten in der GOP begonnen?
• War der Nutzlasttyp konsistent mit SDP?

Sobald diese Fragen beantwortet sind, wird die nächste Aktion klarer.

Warum Stream-Starts in der Mitte der GOP riskant sind

Viele Kameras beginnen mit dem Senden ab der aktuellen Encoderposition, wenn der RTSP-Client eine Verbindung herstellt. Wenn der Client mitten in der GOP beitritt, empfängt er möglicherweise Interframes vor einem Schlüsselframe. Wenn der Stream SPS/PPS auch nicht regelmäßig wiederholt, wartet der Decoder möglicherweise bis zur nächsten geeigneten Grenze oder schlägt fehl.

Für eine Überwachungssoftware kann dies wie folgt aussehen:

• mehrere Sekunden lang schwarzer Bildschirm
• Das erste Bild erscheint erst nach der Bewegung oder dem Keyframe-Intervall
• Die Analytics-Pipeline lehnt den Stream ab
• Der Restreamer startet, aber nachgeschaltete Clients schlagen fehl
• Gelegentliche Erholung nach erneuter Verbindung

Die Lösung kann kameraseitig sein: Keyframe-Intervall verkürzen, Parametersätze wiederholen, ein anderes Stream-Profil verwenden oder von H.265 auf H.264 wechseln, wenn das Downstream-Produkt strengere Unterstützung bietet.

SDP ist ein Anspruch; RTP ist der Beweis

Einige Kamerasysteme bewerben SPS/PPS in SDP. Andere erwarten, dass der Decoder auf In-Band-NAL-Einheiten wartet. Manche machen beides. Manche machen beides nicht richtig. Ein Diagnosebericht sollte den Anspruch mit der Nutzlast vergleichen.

Zu den nützlichen Beweisen gehören:

• Base64-Parametersätze in SDP
• In RTP beobachtete H.264-NAL-Einheitstypen
• erster SPS/PPS-Paketindex
• erster IDR-Paketindex
• Paketverlust vor Keyframe-Bereitschaft
• Decoder-Bereitschaftsstatus

Das ist viel stärker als „versuchen Sie es mit einem anderen Spieler“. Es teilt einem Anbieter mit, ob SDP, Encodereinstellungen oder Paketierungsverhalten geändert werden sollen.

Wo RTSP Inspector passt

RTSP Inspector wurde entwickelt, um RTSP-, SDP-, RTP/RTCP- und Codec-Strukturen zu überprüfen, ohne so zu tun, als wäre die Wiedergabe die Diagnose. Bei fehlenden SPS/PPS-Fällen sollte das Produkt Ingenieuren dabei helfen, Folgendes aufzuzeigen:

• Der Stream wurde erfolgreich verbunden
• SDP trug Parametersätze oder trug keine
• RTP hat Parametersätze geliefert oder nicht geliefert
• Der Paketverlust hatte entweder Auswirkungen auf die erste Dekodiergrenze oder nicht
• Der Fehler liegt an den Stream-Metadaten, der Netzwerkbereitstellung, der Decoder-Unterstützung oder der Kamerakonfiguration

Dies ist die Art von Beweisen, die das Argument „VLC funktioniert“ klären. Die Funktionsweise von VLC ist eine nützliche Information. Es ist kein Beweis dafür, dass der Stream für jeden Verbraucher sauber ist.

Wenn Ihre Suchanfrage lautet „RTSP funktioniert in VLC, aber FFmpeg schlägt fehl“, prüfen Sie SPS/PPS, Schlüsselbilder, Paketverlust und SDP, bevor Sie die Schuld dem Downstream-System geben.