2026-06-02

So beheben Sie Unknown Write-RTP-/NDPI-Fehler – Dynamischer Nutzlasttyp und SDP-Zuordnung in RTSP-Streams

Debuggen Sie RTP-/NDPI-Fehler beim \"unbekannten Schreiben\" in RTSP-Erfassungen, indem Sie dynamische RTP-Nutzlasttypen wieder den SDP-RTPMAP- und FMTP-Zeilen zuordnen. Deckt H.264-, H.265-, AAC-, ONVIF-Metadaten, Nutzlast-IDs und Depaketiererfehler ab.

Eine RTSP-Sitzung kann fehlerfrei aussehen, bis der Medienparser versucht, RTP-Pakete zu verstehen. „DESCRIBE“ gibt SDP zurück. „SETUP“ ist erfolgreich. „PLAY“ ist erfolgreich. RTP-Pakete kommen an. Dann meldet die Anwendung oder der Paketklassifizierer „unbekanntes Schreiben“, „unbekannte RTP-Nutzlast“, „NDPI unbekannt“, „nicht unterstützter Nutzlasttyp“, „Entpaketierer nicht gefunden“, „ungültige Codec-Zuordnung“, „kein Decoder für Nutzlasttyp 96“ oder „Stream enthält unbekannte Spur“.

Diese Fehler bedeuten normalerweise, dass die Bytes vorhanden sind, der Analysator jedoch keinen RTP-Nutzlasttyp der Codec- und Spurdefinition von SDP zuordnen kann. In RTSP ist der Nutzlasttyp „96“ nicht automatisch H.264. Es handelt sich um eine sitzungslokale dynamische ID. Sie müssen das SDP lesen.

Schnelle Antwort: Überprüfen Sie SDP, bevor Sie NDPI oder der Kamera die Schuld geben

Wenn in einer Erfassung „unbekanntes Schreiben“ / „RTP“ / „NDPI“ steht, beginnen Sie hier:

Suchen Sie die RTSP-Antwort „DESCRIBE“.
Kopieren Sie das SDP.
Finden Sie jede „m=“-Medienzeile und ihre Nutzlastnummern.
Suchen Sie für jede dynamische Nutzlast (96-127) die passende Zeile „a=rtpmap:<id>“.
Überprüfen Sie die Zeile „a=fmtp:<id>“ auf Codec-Parameter.
Vergleichen Sie das RTP-Paket-Nutzlasttyp-Byte mit dieser SDP-Zuordnung.

Wenn RTP-Pakete den Nutzlasttyp „96“ verwenden und SDP „a=rtpmap:96 H265/90000“ sagt, wird ein Analysator, der H.264 erwartet, Unsinn melden. Wenn SDP „a=rtpmap:96 vnd.onvif.metadata/90000“ hat, ist die unbekannte Nutzlast überhaupt kein Video; Es handelt sich um ONVIF-Metadaten und sollte die Wiedergabe nicht beenden.

Aus diesem Grund reicht eine generische DPI-Bezeichnung wie „NDPI unbekannt“ nicht aus. DPI-Engines sehen Paketbytes. Sie verfügen nicht immer über den RTSP-Kontrollebenenkontext, der zur Interpretation sitzungslokaler dynamischer Nutzlast-IDs erforderlich ist. Für RTSP müssen Control Plane und Media Plane gemeinsam gelesen werden.

Dies ist ein Protokollinterpretationsproblem. RTSP Inspector ist nützlich, weil es SDP- und RTP-Beweise zusammenhält. Sie können dynamische RTP-Payload-IDs ohne das SDP, das sie definiert, nicht korrekt interpretieren.

Statische vs. dynamische Nutzlasttypen

Einige RTP-Nutzlasttypen sind statisch. Andere sind dynamisch. Dynamische Nutzlasttypen liegen normalerweise im Bereich 96–127 und müssen von SDP zugeordnet werden.

Beispiel:

m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000

Here, payload type 96 means H.264 for this session. In another stream, payload type 96 could mean H.265, AAC, metadata, or something vendor-specific. The number alone is not enough.

If a client assumes payload type 96 is always H.264, it will eventually fail.

SDP rtpmap is required for dynamic payloads

For dynamic payload types, SDP should include a=rtpmap:

a=rtpmap:96 H264/90000
a=rtpmap:97 MPEG4-GENERIC/48000/2
a=rtpmap:98 H265/90000

Wenn SDP „rtpmap“ fehlt, weiß der Client möglicherweise nicht, welchen Depacketizer er verwenden soll. Einige Kameras erzeugen unvollständiges SDP. Einige Relays oder Proxys ändern SDP. Einige Clients analysieren nur allgemeine Spuren und ignorieren Metadatenspuren.

Gemeinsame Ergebnisse:

Die Videonutzlast kommt an, wird aber nicht dekodiert.
Audiospur wird ignoriert.
ONVIF-Metadatenspur löst unbekannte Nutzlastfehler aus.
H.265 wird mit H.264 verwechselt.
AAC-Taktrate oder Kanalanzahl ist falsch.

Der Nutzlasttyp ändert sich zwischen Sitzungen

Kodieren Sie dynamische Payload-IDs nicht fest. Eine Kamera kann nach einem Neustart, einer Profiländerung, einem Firmware-Update oder einer Stream-Pfad-Änderung unterschiedliche Nutzlastnummern zuweisen.

Zum Beispiel:

Session A: payload 96 = H264
Session B: payload 96 = H265
Session C: payload 97 = H264, payload 96 = metadata

The correct behavior is to parse SDP per session and bind RTP packet payload IDs to that session's mapping.

H.264 and H.265 confusion

H.264 and H.265 both often use 90 kHz RTP clocks, but their packetization and codec configuration are different. A client using the H.264 depacketizer for H.265 packets will not produce valid video.

Symptoms:

RTP packets arrive.
Payload type is dynamic.
SDP says H265 but client expects H264.
Decoder reports invalid NAL units.
Video is black or never starts.

Always check SDP before concluding that the camera "sends bad video."

AAC and MPEG4-GENERIC

Audio tracks can be just as tricky. AAC over RTP often uses MPEG4-GENERIC with parameters such as mode, config, sizeLength, indexLength, and profile-level-id.

If the client ignores fmtp, audio may fail even though packets arrive.

Relevant SDP:

a=rtpmap:97 MPEG4-GENERIC/48000/2
a=fmtp:97 streamtype=5; profile-level-id=1; mode=AAC-hbr; config=...

Nutzlasttyp, Taktrate, Kanäle und FMTP-Parameter sind alle wichtig.

Metadaten-Tracks und Anbietererweiterungen

ONVIF-Metadaten, Analyse-Overlays, private Ereignisspuren und herstellerspezifische Nutzlasten können in SDP angezeigt werden. Ein Mediaplayer weiß möglicherweise nicht, was er damit machen soll.

Dies ist nicht unbedingt ein Streamfehler. Dies kann bedeuten, dass der Client nicht unterstützte Nicht-Medientitel ignorieren sollte, während er weiterhin Video und Audio verarbeitet. Wenn der Client jedoch unbekannte Metadaten als schwerwiegend einstuft, kann die Wiedergabe fehlschlagen.

RTSP Inspector soll dabei helfen, den Tracktyp und die Payload-Zuordnung zu identifizieren und festzustellen, ob es sich bei unbekannten Payloads um Video, Audio, Metadaten oder private Daten handelt.

Debug-Checkliste

Verwenden Sie diesen Prozess:

Erfassen Sie das von „DESCRIBE“ zurückgegebene SDP.
Listen Sie jeden „m=“-Medienabschnitt auf.
Listen Sie jeden dynamischen Nutzlasttyp auf.
Ordnen Sie Payload-IDs mit „a=rtpmap“ zu.
Überprüfen Sie „a=fmtp“ auf Codec-Konfiguration.
Vergleichen Sie die Werte des RTP-Paket-Nutzlasttyps mit SDP.
Überprüfen Sie, ob sich Payload-IDs zwischen Sitzungen ändern.
Trennen Sie Video, Audio, Metadaten und private Titel.
Stellen Sie sicher, dass der Client für jeden erforderlichen Codec über einen Depaketierer verfügt.
Ignorieren Sie nicht unterstützte optionale Spuren nur, wenn die Anwendung dies sicher kann.

Endgültige Diagnose

Eine Nichtübereinstimmung des dynamischen RTP-Payload-Typs tritt auf, wenn der Client eingehende RTP-Pakete nicht dem richtigen Codec oder Track zuordnen kann. Die Lösung besteht darin, SDP als Autorität für die Sitzung zu behandeln: „rtpmap“ analysieren, „fmtp“ analysieren, Payload-IDs pro Sitzung binden und erforderliche Medienspuren von optionalen Metadaten unterscheiden.

RTSP Inspector unterstützt diesen evidenzorientierten Arbeitsablauf, indem es SDP und RTP nebeneinander anzeigt, sodass Nutzlastprobleme diagnostiziert werden können, bevor die Schuld der Kamera, dem Decoder oder dem Netzwerk zugeschrieben wird.

Reproduzierbarer Nachweis für „So beheben Sie Unknown Write-RTP-/NDPI-Fehler – Dynamischer Nutzlasttyp und SDP-Zuordnung in RTSP-Streams“

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 „So beheben Sie Unknown Write-RTP-/NDPI-Fehler – Dynamischer Nutzlasttyp und SDP-Zuordnung in RTSP-Streams“ 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.

Direkte Antwort und Abnahmegrenze

Die kurze Antwort zu „So beheben Sie Unknown Write-RTP-/NDPI-Fehler – Dynamischer Nutzlasttyp und SDP-Zuordnung in RTSP-Streams“ lautet: Debuggen Sie RTP-/NDPI-Fehler beim "unbekannten Schreiben" in RTSP-Erfassungen, indem Sie dynamische RTP-Nutzlasttypen wieder den SDP-RTPMAP- und FMTP-Zeilen zuordnen. Deckt H.264-, H.265-, AAC-, ONVIF-Metadaten, Nutzlast-IDs und Depaketiererfehler ab. Behandeln Sie diese Aussage als zu prüfendes Ergebnis und nicht als Versprechen für jede Eingabe, jedes Gerät, jedes Projekt oder jede Umgebung. Ein vollständiges Ergebnis dokumentiert Ausgangszustand, exakte Aktion, sichtbare Ausgabe und die Bedingung, die den Abschluss in RTSP Inspector belegt.

Evidenzorientiertes Vorgehen

Beginnen Sie mit einem kleinen, wiederholbaren Fall, bevor Sie ein vollständiges Projekt verändern. Protokollieren Sie Anwendungsversion, Betriebssystem, Eingabe- oder Geräteidentität, relevante Einstellungen und erwartetes Ergebnis. Führen Sie eine bewusste Aktion aus, bewahren Sie den ersten unerwarteten Übergang und vergleichen Sie möglichst mit einem bekannten guten Lauf. Mehrere gleichzeitige Änderungen verdecken, welche Bedingung den Fehler erzeugt oder behoben hat.

Prüfpunkt 1: So beheben Sie Unknown Write-RTP-/NDPI-Fehler – Dynamischer Nutzlasttyp und SDP-Zuordnung

Schließen Sie „So beheben Sie Unknown Write-RTP-/NDPI-Fehler – Dynamischer Nutzlasttyp und SDP-Zuordnung in RTSP-Streams“ erst, wenn gespeichertes, exportiertes oder erneut geöffnetes Ergebnis weiterhin dem beobachteten Zustand entspricht. Vorübergehendes UI-Feedback hilft, dauerhafte Evidenz ist aber stärker. Dokumentieren Sie verbleibende Grenzen für die nächste Person.

Prüfpunkt 2: Debuggen Sie RTP-/NDPI-Fehler beim "unbekannten Schreiben" in RTSP-Erfassungen, indem Si

Trennen Sie bei „Debuggen Sie RTP-/NDPI-Fehler beim "unbekannten Schreiben" in RTSP-Erfassungen, indem Sie dynamische RTP-Nutzlasttypen wieder den SDP-RTPMAP- und FM“ eine Produktentscheidung von Grenzen des Betriebssystems, der Hardware, Quelldatei, Berechtigung oder Arbeitsweise. Bestätigen Sie zuerst, welche Schicht die Evidenz geliefert hat. So wird ein benachbartes Symptom nicht fälschlich zur bewiesenen Ursache.

Prüfpunkt 3: Schnelle Antwort: Überprüfen Sie SDP, bevor Sie NDPI oder der Kamera die Schuld geben

Schließen Sie „Schnelle Antwort: Überprüfen Sie SDP, bevor Sie NDPI oder der Kamera die Schuld geben“ erst, wenn gespeichertes, exportiertes oder erneut geöffnetes Ergebnis weiterhin dem beobachteten Zustand entspricht. Vorübergehendes UI-Feedback hilft, dauerhafte Evidenz ist aber stärker. Dokumentieren Sie verbleibende Grenzen für die nächste Person.

Prüfpunkt 4: Statische vs. dynamische Nutzlasttypen

Trennen Sie bei „Statische vs. dynamische Nutzlasttypen“ eine Produktentscheidung von Grenzen des Betriebssystems, der Hardware, Quelldatei, Berechtigung oder Arbeitsweise. Bestätigen Sie zuerst, welche Schicht die Evidenz geliefert hat. So wird ein benachbartes Symptom nicht fälschlich zur bewiesenen Ursache.

Prüfpunkt 5: SDP rtpmap is required for dynamic payloads

Schließen Sie „SDP rtpmap is required for dynamic payloads“ erst, wenn gespeichertes, exportiertes oder erneut geöffnetes Ergebnis weiterhin dem beobachteten Zustand entspricht. Vorübergehendes UI-Feedback hilft, dauerhafte Evidenz ist aber stärker. Dokumentieren Sie verbleibende Grenzen für die nächste Person.

Prüfpunkt 6: Der Nutzlasttyp ändert sich zwischen Sitzungen

Trennen Sie bei „Der Nutzlasttyp ändert sich zwischen Sitzungen“ eine Produktentscheidung von Grenzen des Betriebssystems, der Hardware, Quelldatei, Berechtigung oder Arbeitsweise. Bestätigen Sie zuerst, welche Schicht die Evidenz geliefert hat. So wird ein benachbartes Symptom nicht fälschlich zur bewiesenen Ursache.

Prüfpunkt 7: H.264 and H.265 confusion

Schließen Sie „H.264 and H.265 confusion“ erst, wenn gespeichertes, exportiertes oder erneut geöffnetes Ergebnis weiterhin dem beobachteten Zustand entspricht. Vorübergehendes UI-Feedback hilft, dauerhafte Evidenz ist aber stärker. Dokumentieren Sie verbleibende Grenzen für die nächste Person.

Prüfpunkt 8: AAC and MPEG4-GENERIC

Trennen Sie bei „AAC and MPEG4-GENERIC“ eine Produktentscheidung von Grenzen des Betriebssystems, der Hardware, Quelldatei, Berechtigung oder Arbeitsweise. Bestätigen Sie zuerst, welche Schicht die Evidenz geliefert hat. So wird ein benachbartes Symptom nicht fälschlich zur bewiesenen Ursache.

Prüfpunkt 9: Metadaten-Tracks und Anbietererweiterungen

Schließen Sie „Metadaten-Tracks und Anbietererweiterungen“ erst, wenn gespeichertes, exportiertes oder erneut geöffnetes Ergebnis weiterhin dem beobachteten Zustand entspricht. Vorübergehendes UI-Feedback hilft, dauerhafte Evidenz ist aber stärker. Dokumentieren Sie verbleibende Grenzen für die nächste Person.

Prüfpunkt 10: Debug-Checkliste

Trennen Sie bei „Debug-Checkliste“ eine Produktentscheidung von Grenzen des Betriebssystems, der Hardware, Quelldatei, Berechtigung oder Arbeitsweise. Bestätigen Sie zuerst, welche Schicht die Evidenz geliefert hat. So wird ein benachbartes Symptom nicht fälschlich zur bewiesenen Ursache.

Abnahmematrix

Prüfpunkt	Aufzubewahrender Nachweis	Passkriterium
So beheben Sie Unknown Write-RTP-/NDPI-Fehler – Dynamischer Nutzlasttyp und SDP-Zuordnung in RTSP-Streams	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Debuggen Sie RTP-/NDPI-Fehler beim "unbekannten Schreiben" in RTSP-Erfassungen, indem Sie dynamische RTP-Nutzlasttypen	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Schnelle Antwort: Überprüfen Sie SDP, bevor Sie NDPI oder der Kamera die Schuld geben	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Statische vs. dynamische Nutzlasttypen	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
SDP rtpmap is required for dynamic payloads	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Der Nutzlasttyp ändert sich zwischen Sitzungen	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren

Fehlerisolierung, Recovery und Übergabe

Stoppen Sie beim ersten fehlerhaften Übergang. Bewahren Sie Quelle, Projekt, Session oder Capture und erstellen Sie vor destruktiven Änderungen eine Kopie. Ändern Sie pro Experiment nur eine Variable. Ein kompletter erneuter Lauf nach mehreren Änderungen kann anders enden, ohne die Ursache zu erklären.

Unterscheiden Sie fehlende Evidenz von Evidenz für ein Fehlen. Eine leere Ansicht kann auf falsche Eingabe, Scope, Filter, Berechtigung, Gerät, Zeitbereich oder Projektzustand hinweisen. Beweisen Sie Aufnahme oder Import, bevor Sie Decoder, Editor, Bericht oder Export interpretieren.

Öffnen Sie vor der Übergabe das dauerhafte Artefakt erneut und prüfen Sie Anfang, Entscheidungsstelle und Ende. Dokumentieren Sie Version, Plattform, Konfiguration, Erwartung, Beobachtung und kleinste Reproduktion. Entfernen oder schwärzen Sie sensible Daten und prüfen Sie die Berechtigung des Empfängers.

Fragen und Antworten

Wie beginnt man am schnellsten zuverlässig?

Verwenden Sie den kleinsten repräsentativen Fall, notieren Sie das erwartete Ergebnis und ändern Sie nur eine Variable. Beweisen Sie den Grundpfad, bevor Filter, Effekte, Bearbeitungen, Automatisierung oder größere Quellen hinzukommen.

Welche Evidenz sollte gespeichert werden?

Bewahren Sie Eingabeidentität, Version, Plattform, Einstellungen, exakte Aktion, ersten unerwarteten Übergang und Endausgabe. Projekt, Session, Bericht oder Export müssen geschlossen und erneut geöffnet werden.

Wann sollte das Verfahren wiederholt werden?

Wiederholen Sie es nach relevanten Änderungen an Anwendung, Betriebssystem, Treiber, Firmware, Modell, Quelle oder Workflow. Behalten Sie den früher akzeptierten Fall als unveränderte Vergleichsbasis.

Wann ist die Aufgabe übergabefähig?

Wenn eine autorisierte zweite Person Eingabe und Aktion erkennt, dasselbe Ergebnis reproduziert, verbleibende Grenzen versteht und das gespeicherte Artefakt ohne undokumentierten lokalen Zustand öffnen kann.