2026-06-02

H.264 FU-A RTP Fragmentation Fix: Warum Ihr RTSP-Video kaputt ist (Paketverlust, NAL-Zusammenbau)

Repariert defektes RTSP-Video aufgrund von H.264 FU-A RTP-Fragmentierung. Deckt fehlende Fragmente, Start-/Endbitfehler, NAL-Reassemblierungsfehler, Paketverlust, MTU und Decoderfehler mit echten Diagnosebefehlen ab.

H.264 über RTP bricht auf eine Art und Weise zusammen, die wie Decoderfehler aussieht, in Wirklichkeit aber Paketierungsprobleme darstellt. Die RTSP-Sitzung funktioniert. DESCRIBE gibt gültiges SDP zurück. SETUP ist erfolgreich. PLAY gibt 200 OK zurück. RTP-Pakete kommen mit dem richtigen Nutzlasttyp an, der H.264 zugeordnet ist. Dennoch zeigt das Video Blockbeschädigungen, Einfrierungen, schwarze Frames oder Decoderfehler.

Die Fehler sehen in Ihren Protokollen so aus:

[h264 @ 0x...] invalid NAL unit size
[h264 @ 0x...] missing picture in access unit
[h264 @ 0x...] non-existing PPS 0 referenced
[h264 @ 0x...] decode_slice_header error
[h264 @ 0x...] no frame!

The fast answer

Why fragmentation exists

The structure of an FU-A packet

Each FU-A RTP packet contains:

Byte 0: FU indicator
  bit 7: F (forbidden_zero_bit) — normally 0
  bits 6-5: NRI (nal_ref_idc) — priority
  bits 4-0: Type = 28 (FU-A)
Byte 1: FU header
  bit 7: S (Start) — 1 for first fragment
  bit 6: E (End) — 1 for last fragment
  bit 5: R (Reserved) — always 0
  bits 4-0: Type — original NAL unit type (1=non-IDR, 5=IDR, 7=SPS, 8=PPS)
Byte 2+: Fragment payload — the actual NAL unit data

Eine vollständige FU-A-Sequenz für eine NAL-Einheit:

Packet 1: FU indicator (type=28) | FU header (S=1, E=0, type=5) | payload[0..N]
Packet 2: FU indicator (type=28) | FU header (S=0, E=0, type=5) | payload[N+1..M]
Packet 3: FU indicator (type=28) | FU header (S=0, E=0, type=5) | payload[M+1..P]
Packet 4: FU indicator (type=28) | FU header (S=0, E=1, type=5) | payload[P+1..END]

The RTP marker bit

Failure modes: what breaks and why

Failure 1: Missing middle fragment

Expected:  1000(S)  1001(M)  1002(M)  1003(E|marker)
Received:  1000(S)  1001(M)  [LOST]   1003(E|marker)

Der Reassembler sieht ein Startfragment, ein mittleres Fragment und dann ein Endfragment – aber die Nutzlastbytes verbinden sich nicht. Die wieder zusammengebaute NAL-Einheit weist eine Lücke auf.

Symptome:

Blockieren Sie Beschädigungen in einem horizontalen Streifen des Rahmens
Decoder meldet „ungültige NAL-Einheitsgröße“
Die Korruption ist auf eine Zugriffseinheit beschränkt (wird beim nächsten IDR gelöscht)

Fehler 2: Fehlendes Startfragment

Expected:  1000(S)  1001(M)  1002(E)
Received:  [LOST]   1001(M)  1002(E)

Failure 3: Missing end fragment

Expected:  1000(S)  1001(M)  1002(E|marker)
Received:  1000(S)  1001(M)  [LOST]

Der Reassembler sieht das Endfragment nie. Die NAL-Einheitsgrenze wird nie bestätigt. Der Decoder wartet auf weitere Daten, die nie eintreffen.

Symptome:

Video friert ein
Decoder meldet „fehlendes Bild in der Zugangseinheit“
Die Wiedergabe bleibt stehen, bis die nächste vollständige Zugriffseinheit eintrifft

Fehler 4: Fragmente außerhalb der Reihenfolge

Expected:  1000(S)  1001(M)  1002(E)
Received:  1000(S)  1002(E)  1001(M)

Diagnostic workflow

Step 1: Confirm H.264 payload mapping

m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=4D0029;sprop-parameter-sets=...

„packetization-mode=1“ bedeutet nicht-interleaved Modus (FU-A wird unterstützt)
„packetization-mode=0“ bedeutet Einzel-NAL-Einheitsmodus (keine Fragmentierung – sehr begrenzt)

Schritt 2: Verfolgen Sie RTP-Sequenznummern

Achten Sie in Ihrer Aufnahme auf die RTP-Sequenznummern für die Videospur. Lücken weisen auf einen Paketverlust hin:

Seq 1000: FU-A Start, NAL type 5 (IDR)
Seq 1001: FU-A middle
Seq 1003: FU-A End, marker=1   ← gap at 1002

Step 3: Inspect FU-A headers

Byte 0 (FU indicator):
  0x7C = NRI=3, Type=28 (FU-A)

Byte 1 (FU-Header):
  0x85 = S=1, E=0, R=0, Typ=5 (IDR-Slice) ← Startfragment von IDR
  0x45 = S=0, E=0, R=0, Typ=5 ← mittleres Fragment
  0x65 = S=0, E=1, R=0, Typ=5 ← Endfragment; Marker nur, wenn diese NAL-Einheit die Access Unit beendet

Zu suchende falsche Werte:

S=1 bei einem Nicht-Startpaket → Verwirrung beim Reassembler
Marker vor E=1 gesetzt → falsche Access-Unit-Grenze
E=1 ohne Marker kann gültig sein, wenn danach eine weitere NAL-Einheit folgt
Typänderungen mitten in der Sequenz → Encoder-Fehler oder Stream-Beschädigung

Schritt 4: Überprüfen Sie den vollständigen Zusammenbau

Für jede NAL-Einheit:

Finden Sie das Startfragment (S=1)
Folgen Sie aufeinanderfolgenden Sequenznummern bis zum Endfragment (E=1).
Fragmente zählen; Stellen Sie sicher, dass keine Sequenzlücken vorhanden sind
Vergleichen Sie den Marker mit der Access-Unit-Grenze; er ist nicht bei jedem FU-A-Endfragment erforderlich
Stellen Sie sicher, dass alle Fragmente denselben Zeitstempel und NAL-Typ haben

Schritt 5: Transportarten vergleichen

Führen Sie denselben Stream über UDP und TCP interleaved aus. Wenn das Video über TCP sauber, über UDP jedoch beschädigt ist, liegt das Problem am Netzwerkpaketverlust und nicht an Encoder- oder Decoderproblemen.

Schritt 6: IDR- und Nicht-IDR-Analyse

IDR-Frames sind größer und erfordern mehr FU-A-Fragmente pro NAL-Einheit. Mehr Fragmente = höheres Risiko für Paketverluste. Wenn die Beschädigung hauptsächlich bei Szenenwechseln oder alle paar Sekunden (im IDR-Intervall) auftritt, sind die IDR-Frames das Opfer.

Optionen beheben:

Verringern Sie die IDR-Framegröße (reduzieren Sie die Auflösung oder Bitrate für Keyframes).
Erhöhen Sie das IDR-Intervall (weniger große Frames, aber langsamere Wiederherstellung nach Verlust)
Reduzieren Sie die MTU für FU-A am Encoder (mehr Fragmente, aber jedes ist kleiner und löst mit geringerer Wahrscheinlichkeit eine IP-Fragmentierung aus)

Wiederherstellungsstrategien

Beim Reassembler

Lassen Sie beschädigte Zugriffseinheiten vollständig fallen, anstatt Teildaten an den Decoder weiterzuleiten
Fordern Sie einen neuen IDR-Frame über RTCP an (sofern von der Kamera unterstützt)
Warten Sie auf den nächsten IDR-Frame (Decoder wird automatisch wiederhergestellt)

Am Encoder

Senken Sie die Größenbeschränkung für NAL-Einheiten, um Fragmente pro Zugriffseinheit zu reduzieren
Verwenden Sie regelmäßige Intra-Refresh-Frames anstelle vollständiger IDR-Frames (kleinere Keyframes).
Aktivieren Sie FEC (Forward Error Correction), wenn der RTP-Stack dies unterstützt

Im Netzwerk

Wechseln Sie von UDP zu TCP interleaved, wenn ein Paketverlust unvermeidbar ist
Stellen Sie sicher, dass die Pfad-MTU-Erkennung funktioniert (IP-Fragmentierung vermeiden)
Priorisieren Sie den RTP-Verkehr auf überlasteten Verbindungen

Wenn es nicht FU-A ist

Nicht jede H.264-Korruption ist eine FU-A-Fragmentierung. Überprüfen:

SPS/PPS fehlt: Decoderfehler wie „nicht vorhandener PPS“ – überprüfen Sie die SDP-Sprop-Parametersätze
Falsches Profil/Level: Decoder kann die Stream-Komplexität nicht bewältigen
Encoder-Fehler: Der Encoder erzeugt eine ungültige NAL-Einheitssyntax
Bitstream-Beschädigung an der Quelle: Der Encoder der Kamera ist defekt, nicht das Netzwerk

Wenn die RTP-Pakete mit perfekten Sequenznummern und korrekten FU-A-Headern ankommen, der Decoder aber trotzdem ausfällt, liegt das Problem im H.264-Bitstrom selbst und nicht im Transport.

Reproduzierbarer Nachweis für „H.264 FU-A RTP Fragmentation Fix: Warum Ihr RTSP-Video kaputt ist (Paketverlust, NAL-Zusammenbau)“

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 „H.264 FU-A RTP Fragmentation Fix: Warum Ihr RTSP-Video kaputt ist (Paketverlust, NAL-Zusammenbau)“ 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.

Von der Beobachtung zum überprüfbaren Schichturteil

Schreiben Sie bei „H.264 FU-A RTP Fragmentation Fix: Warum Ihr RTSP-Video kaputt ist (Paketverlust, NAL-Zusammenbau)“ zuerst die Beobachtung und erst danach die Interpretation. Eine Beobachtung kann eine zweite Person im Mitschnitt finden: RTSP-Status mit CSeq, SDP-Wert, Transport-Antwort, Lücke zwischen Sequenznummern, SSRC-Wechsel oder Abweichung zwischen RTP-Timestamp und RTCP Sender Report. „Der Server ist langsam“ oder „der Codec ist inkompatibel“ bleibt eine Hypothese, bis ein konkreter Beleg sie besser erklärt als die Alternativen.

Teilen Sie den Ablauf in Grenzen. Zuerst muss TCP geöffnet werden. Danach müssen OPTIONS oder DESCRIBE akzeptiert werden. SDP muss einen verwendbaren Track, Control-Pfad, Payload-Typ und eine Clock Rate beschreiben. SETUP braucht eine passende Transport-Antwort, PLAY eine gültige Session. Erst danach folgen RTP-Ankunft, Reihenfolge, Timing und Decoderbereitschaft. Stoppen Sie an der ersten Grenze ohne Erfolgsbeleg; spätere Pakete dürfen eine frühere Lücke nicht verdecken.

Halten Sie bei Vergleichstests Quelle und Zeitbereich möglichst konstant. UDP gegen TCP interleaved wird mit identischem Pfad und denselben Zugangsdaten geprüft. Main Stream gegen Sub Stream benötigt denselben Client und Transport. Beim Vergleich VLC gegen VMS dokumentieren Sie die tatsächlich gesendeten Methoden, Header und URLs. Ein Unterschied bei control URL, Authorization, Session oder Keepalive erklärt das Ergebnis oft besser als der Produktname.

Ausschlussmatrix

Beginnen Sie mit zwei Hypothesen. Wenn keine Medien ankommen, könnten UDP-Pakete blockiert sein oder der Server könnte an andere Ports senden. TCP interleaved prüft die erste Möglichkeit; der Vergleich von Transport-Angebot, Antwort, IP-Adressen und Ports prüft die zweite. Bei beschädigtem Bild trennen Sequenznummern RTP-Verlust von fehlender Codec-Initialisierung, während SPS/PPS/VPS vor dem ersten Frame die Parameterhypothese prüft.

Notieren Sie für jede Hypothese einen bestätigenden und einen widerlegenden Beleg. Eine Aussage, die kein Paket widerlegen kann, ist zu breit. „NAT verwirft UDP“ wird durch RTP am Client-Port widerlegt. „H.264-Parameter fehlen“ wird durch gültige SPS und PPS vor einem IDR widerlegt. Diese Form hält den Bericht priorisiert und verhindert eine ungeordnete Liste möglicher Ursachen.

Zeit korrekt einordnen

RTSP CSeq ordnet Steuerungstransaktionen, RTP Sequence ordnet Pakete, RTP Timestamp beschreibt Medienabtastzeit und die Capture-Uhr die Ankunft am Messpunkt. Setzen Sie diese Uhren nicht gleich. Schwankende Ankunftszeit beweist keinen Timestamp-Drift; ein Timestamp-Sprung beweist ohne Sequenzbeleg keinen Paketverlust. Für Audio-/Video-Synchronität verbinden RTCP Sender Reports die getrennten RTP-Uhren mit einer gemeinsamen Referenz.

Abnahmepaket

Schließen Sie die Untersuchung erst, wenn sich die Korrektur in einer neuen Verbindung mit einer dokumentierten Änderung wiederholen lässt. Der Bericht nennt Eingaben, letzte erfolgreiche Grenze, ersten fehlgeschlagenen Beleg, Änderung, Wiederholungsergebnis und offene Tests. Fügen Sie einen kleinen relevanten Transkriptausschnitt oder Paketstatistiken bei. Entfernen Sie Geheimnisse, aber behalten Sie CSeq, bereinigte Session, SSRC und Zeitbereich.

Mit der RTSP-Fehlersuche lässt sich der Ablauf erneut prüfen; RTSP-Inspector-Berichte übergeben die belegte Fehlergrenze an Kamera-, Netzwerk- oder VMS-Teams.