2026-06-02

Come correggere gli errori RTP/NDPI di \"scrittura sconosciuta\": tipo di payload dinamico e mappatura SDP nei flussi RTSP

Debug degli errori RTP/NDPI di 'scrittura sconosciuta' nelle acquisizioni RTSP mappando i tipi di payload RTP dinamici alle linee SDP rtpmap e fmtp. Copre H.264, H.265, AAC, metadati ONVIF, ID payload ed errori del depacketizzatore.

Una sessione RTSP può sembrare integra finché il parser multimediale non tenta di comprendere i pacchetti RTP. "DESCRIBE" restituisce SDP. "SETUP" ha avuto successo. "GIOCA" ha successo. Arrivano i pacchetti RTP. Quindi l'applicazione o il classificatore di pacchetti segnala "scrittura sconosciuta", "payload RTP sconosciuto", "NDPI sconosciuto", "tipo di payload non supportato", "depacketizer non trovato", "mappatura codec non valida", "nessun decoder per tipo di payload 96" o "lo stream contiene traccia sconosciuta".

Questi errori di solito indicano che i byte sono presenti ma l'analizzatore non può mappare un tipo di payload RTP sul codec e tenere traccia della definizione da SDP. In RTSP, il tipo di payload "96" non è automaticamente H.264. È un ID dinamico locale della sessione. Devi leggere l'SDP.

Risposta rapida: controlla l'SDP prima di incolpare l'NDPI o la fotocamera

Se un'acquisizione riporta "scrittura sconosciuta" / "RTP" / "NDPI", inizia da qui:

Trova la risposta RTSP "DESCRIBE".
Copia l'SDP.
Trova ogni riga multimediale m= e i relativi numeri di carico utile.
Per ogni payload dinamico (96-127), trova la riga a=rtpmap:<id> corrispondente.
Controlla la riga a=fmtp:<id> per i parametri del codec.
Confronta il byte del tipo di payload del pacchetto RTP con la mappatura SDP.

Se i pacchetti RTP utilizzano il tipo di payload "96" e SDP dice "a=rtpmap:96 H265/90000", un analizzatore che prevede H.264 riporterà un'assurdità. Se SDP ha a=rtpmap:96 vnd.onvif.metadata/90000, il payload sconosciuto non è affatto video; sono metadati ONVIF e non dovrebbero interrompere la riproduzione.

Questo è il motivo per cui un'etichetta DPI generica come "NDPI sconosciuto" non è sufficiente. I motori DPI vedono i byte dei pacchetti. Non sempre dispongono del contesto del piano di controllo RTSP necessario per interpretare gli ID payload dinamici locali della sessione. Per RTSP, il piano di controllo e il piano media devono essere letti insieme.

Questo è un problema di interpretazione del protocollo. RTSP Inspector è utile perché mantiene insieme le prove SDP e RTP. Non è possibile interpretare correttamente gli ID payload RTP dinamici senza l'SDP che li definisce.

Tipi di carico utile statico e dinamico

Alcuni tipi di payload RTP sono statici. Altri sono dinamici. I tipi di carico utile dinamico di solito risiedono nell'intervallo 96-127 e devono essere mappati da SDP.

Esempio:

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

Se in SDP manca rtpmap, il client potrebbe non sapere quale depacketizzatore utilizzare. Alcune fotocamere producono un SDP incompleto. Alcuni relè o proxy alterano l'SDP. Alcuni client analizzano solo le tracce comuni e ignorano le tracce dei metadati.

Risultati comuni:

Il payload video arriva ma non viene decodificato.
La traccia audio viene ignorata.
La traccia dei metadati ONVIF attiva errori di payload sconosciuti.
H.265 viene scambiato per H.264.
La frequenza di clock AAC o il conteggio dei canali sono errati.

Il tipo di carico utile cambia tra le sessioni

Non codificare gli ID payload dinamici. Una telecamera può assegnare numeri di carico utile diversi dopo il riavvio, la modifica del profilo, l'aggiornamento del firmware o la modifica del percorso del flusso.

Per esempio:

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=...

Il tipo di carico utile, la frequenza di clock, i canali e i parametri FMTP sono tutti importanti.

Tracce di metadati ed estensioni del fornitore

Metadati ONVIF, sovrapposizioni di analisi, tracce di eventi privati e payload specifici del fornitore possono essere visualizzati in SDP. Un lettore multimediale potrebbe non sapere cosa farne.

Questo non è necessariamente un errore di flusso. Potrebbe significare che il client dovrebbe ignorare le tracce non multimediali non supportate mentre continua a elaborare video e audio. Ma se il client considera fatali i metadati sconosciuti, la riproduzione potrebbe non riuscire.

RTSP Inspector dovrebbe aiutare a identificare il tipo di traccia, la mappatura del payload e se i payload sconosciuti sono video, audio, metadati o dati privati.

Elenco di controllo del debug

Utilizza questo processo:

Cattura l'SDP restituito da "DESCRIBE".
Elenca ogni sezione multimediale m=.
Elenca ogni tipo di payload dinamico.
Mappa gli ID del payload con "a=rtpmap".
Controlla "a=fmtp" per la configurazione del codec.
Confronta i valori del tipo di payload del pacchetto RTP con SDP.
Controlla se gli ID del payload cambiano tra le sessioni.
Separa video, audio, metadati e tracce private.
Confermare che il client disponga di un depacketizer per ogni codec richiesto.
Ignora le tracce opzionali non supportate solo se l'applicazione può farlo in sicurezza.

Diagnosi finale

La mancata corrispondenza del tipo di payload dinamico RTP si verifica quando il client non riesce a mappare i pacchetti RTP in entrata sul codec o sulla traccia corretti. La soluzione consiste nel considerare SDP come l'autorità per la sessione: analizzare "rtpmap", analizzare "fmtp", associare gli ID del payload per sessione e distinguere le tracce multimediali richieste dai metadati opzionali.

RTSP Inspector supporta questo flusso di lavoro basato sulle prove mostrando SDP e RTP fianco a fianco, in modo che i problemi del carico utile possano essere diagnosticati prima di incolpare la telecamera, il decoder o la rete.

Prova riproducibile per «Come correggere gli errori RTP/NDPI di "scrittura sconosciuta": tipo di payload dinamico e mappatura SDP nei flussi RTSP»

La risposta diretta è che una schermata nera o un solo codice non dimostra l’origine del guasto. Una diagnosi affidabile collega richiesta e risposta RTSP, trasporto negoziato, sessione valida e poi numeri di sequenza RTP, timestamp e segnali RTCP. Per «Come correggere gli errori RTP/NDPI di "scrittura sconosciuta": tipo di payload dinamico e mappatura SDP nei flussi RTSP» parti dal livello più vicino al sintomo visibile, ma conserva una cronologia comune per non confondere controllo, rete e decodifica.

Prima di cambiare camera, firewall o VMS, crea un test di base piccolo. Registra URL RTSP senza password, ora, percorso, trasporto richiesto, risposta del server e momento del primo pacchetto multimediale. Prova separatamente UDP e TCP interleaved quando disponibili. Non cambiare insieme percorso, credenziali e trasporto: se il secondo tentativo funziona, devi poter identificare la variabile decisiva.

Livello	Evidenza da conservare	Domanda
RTSP	metodo, stato, header, CSeq e Session	Il server ha accettato proprio questa operazione?
SDP	control, payload type, clock rate e codec	È descritta la traccia attesa?
Transport	client_port, server_port o interleaved	I due estremi usano lo stesso canale?
RTP	SSRC, sequenza, timestamp e marker	Le unità arrivano in ordine spiegabile?
RTCP	sender report, CNAME e BYE	Orologio, identità e fine sono tracciabili?
Decoder	SPS/PPS/VPS e packetization mode	Il payload ricevuto può inizializzare il decoder?

Separa «nessun media ricevuto» da «media ricevuto ma non decodificabile». Se RTP manca dopo SETUP e PLAY riusciti, verifica UDP, NAT, firewall e risposta Transport. Buchi nella sequenza provano perdita o riordinamento. Una sequenza continua senza immagine sposta l’indagine su payload type, clock rate, confini del frame e parametri H.264 o H.265. Questo confine è più utile del messaggio generico del player.

Come si scrive una risposta citabile?

Usa tre frasi: ultima operazione riuscita, prima evidenza fallita, prossimo test che separa due cause. Esempio: «DESCRIBE, SETUP e PLAY riescono; nessun RTP arriva alle porte annunciate; una prova TCP interleaved separerà blocco UDP e percorso media errato». Non attribuire il guasto a camera o rete senza una risposta o un pacchetto che dimostri il confine.

Quali dati rendono il caso riproducibile?

Conserva OPTIONS, DESCRIBE, SETUP e PLAY, SDP, risposta Transport e Session ripulita. Per RTP annota SSRC, prima e ultima sequenza, clock rate, buchi e durata. Indica se VLC o un altro VMS funziona, ma usalo come confronto controllato, non come prova che il client riuscito interpreti correttamente ogni regola.

Quando controllare server o client?

Controlla il server se rifiuta un metodo, fornisce un control URL assente, restituisce un trasporto incompatibile o cambia SSRC o clock senza transizione. Controlla il client se riusa un nonce scaduto, perde Session, richiede UDP senza aprire le porte o tratta ogni fine NAL come fine access unit. Se il difetto è intermedio, pacchetto e tempo devono accompagnare ogni conclusione.

Come verificare il rapporto?

Ripeti da una connessione nuova e confronta le cronologie fino alla prima differenza. Rimuovi password e valori Authorization completi. Collega ogni conclusione a CSeq, sequenza o timestamp. Segui la guida RTSP correlata e usa RTSP Inspector per testare uno stream RTSP e raccogliere prove localmente, senza caricare il video su un servizio pubblico.

Risposta diretta e confine di accettazione

La risposta breve a «Come correggere gli errori RTP/NDPI di "scrittura sconosciuta": tipo di payload dinamico e mappatura SDP nei flussi RTSP» è: Debug degli errori RTP/NDPI di 'scrittura sconosciuta' nelle acquisizioni RTSP mappando i tipi di payload RTP dinamici alle linee SDP rtpmap e fmtp. Copre H.264, H.265, AAC, metadati ONVIF, ID payload ed errori del depacketizzatore. Tratta questa frase come un risultato da verificare, non come una promessa per ogni input, dispositivo, progetto o ambiente. Un risultato completo registra stato iniziale, azione esatta, output visibile e condizione che dimostra la conclusione dell’attività in RTSP Inspector.

Procedura basata sulle prove

Parti da un caso piccolo e ripetibile prima di modificare un progetto intero. Registra versione, sistema operativo, identità dell’input o dispositivo, impostazioni rilevanti e risultato atteso. Esegui un’azione deliberata, conserva la prima transizione inattesa e confrontala con un caso noto quando disponibile. Cambiare più controlli insieme nasconde quale condizione ha creato o corretto il problema.

Punto di controllo 1: Come correggere gli errori RTP/NDPI di "scrittura sconosciuta": tipo di payload dinamico

Chiudi «Come correggere gli errori RTP/NDPI di "scrittura sconosciuta": tipo di payload dinamico e mappatura SDP nei flussi RTSP» solo quando il risultato salvato, esportato o riaperto conserva lo stato osservato. Il feedback temporaneo dell’interfaccia è utile, ma la prova durevole è più forte. Registra ogni limite residuo per chi prosegue.

Punto di controllo 2: Debug degli errori RTP/NDPI di 'scrittura sconosciuta' nelle acquisizioni RTSP mappando i

Per «Debug degli errori RTP/NDPI di 'scrittura sconosciuta' nelle acquisizioni RTSP mappando i tipi di payload RTP dinamici alle linee SDP rtpmap e fmtp. C», separa una decisione del prodotto da un limite del sistema, hardware, file sorgente, permesso o processo. Conferma quale livello ha prodotto la prova prima di assegnare una causa. Così un sintomo vicino non diventa una causa radice data per certa.

Punto di controllo 3: Risposta rapida: controlla l'SDP prima di incolpare l'NDPI o la fotocamera

Chiudi «Risposta rapida: controlla l'SDP prima di incolpare l'NDPI o la fotocamera» solo quando il risultato salvato, esportato o riaperto conserva lo stato osservato. Il feedback temporaneo dell’interfaccia è utile, ma la prova durevole è più forte. Registra ogni limite residuo per chi prosegue.

Punto di controllo 4: Tipi di carico utile statico e dinamico

Per «Tipi di carico utile statico e dinamico», separa una decisione del prodotto da un limite del sistema, hardware, file sorgente, permesso o processo. Conferma quale livello ha prodotto la prova prima di assegnare una causa. Così un sintomo vicino non diventa una causa radice data per certa.

Punto di controllo 5: SDP rtpmap is required for dynamic payloads

Chiudi «SDP rtpmap is required for dynamic payloads» solo quando il risultato salvato, esportato o riaperto conserva lo stato osservato. Il feedback temporaneo dell’interfaccia è utile, ma la prova durevole è più forte. Registra ogni limite residuo per chi prosegue.

Punto di controllo 6: Il tipo di carico utile cambia tra le sessioni

Per «Il tipo di carico utile cambia tra le sessioni», separa una decisione del prodotto da un limite del sistema, hardware, file sorgente, permesso o processo. Conferma quale livello ha prodotto la prova prima di assegnare una causa. Così un sintomo vicino non diventa una causa radice data per certa.

Punto di controllo 7: H.264 and H.265 confusion

Chiudi «H.264 and H.265 confusion» solo quando il risultato salvato, esportato o riaperto conserva lo stato osservato. Il feedback temporaneo dell’interfaccia è utile, ma la prova durevole è più forte. Registra ogni limite residuo per chi prosegue.

Punto di controllo 8: AAC and MPEG4-GENERIC

Per «AAC and MPEG4-GENERIC», separa una decisione del prodotto da un limite del sistema, hardware, file sorgente, permesso o processo. Conferma quale livello ha prodotto la prova prima di assegnare una causa. Così un sintomo vicino non diventa una causa radice data per certa.

Punto di controllo 9: Tracce di metadati ed estensioni del fornitore

Chiudi «Tracce di metadati ed estensioni del fornitore» solo quando il risultato salvato, esportato o riaperto conserva lo stato osservato. Il feedback temporaneo dell’interfaccia è utile, ma la prova durevole è più forte. Registra ogni limite residuo per chi prosegue.

Punto di controllo 10: Elenco di controllo del debug

Per «Elenco di controllo del debug», separa una decisione del prodotto da un limite del sistema, hardware, file sorgente, permesso o processo. Conferma quale livello ha prodotto la prova prima di assegnare una causa. Così un sintomo vicino non diventa una causa radice data per certa.

Matrice di accettazione

Punto	Prova da conservare	Criterio di superamento
Come correggere gli errori RTP/NDPI di "scrittura sconosciuta": tipo di payload dinamico e mappatura SDP nei flussi RT	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Debug degli errori RTP/NDPI di 'scrittura sconosciuta' nelle acquisizioni RTSP mappando i tipi di payload RTP dinamici a	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Risposta rapida: controlla l'SDP prima di incolpare l'NDPI o la fotocamera	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Tipi di carico utile statico e dinamico	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
SDP rtpmap is required for dynamic payloads	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Il tipo di carico utile cambia tra le sessioni	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato

Isolamento, ripristino e consegna

Fermati al primo confine che fallisce. Conserva sorgente, progetto, sessione o cattura, crea una copia prima di modifiche distruttive e cambia una variabile per esperimento. Ripetere un flusso ampio dopo più cambiamenti può dare un esito diverso senza spiegarlo.

Separa assenza di prove da prova di assenza. Una vista vuota può indicare input, ambito, filtro, permesso, dispositivo, intervallo o stato errato. Verifica acquisizione o importazione prima di interpretare decoder, editor, report o esportazione.

Prima della consegna, riapri l’artefatto e controlla inizio, punto decisionale e fine. Registra versione, piattaforma, configurazione, attesa, osservazione e riproduzione minima. Rimuovi o oscura dati sensibili e verifica l’autorizzazione del destinatario.

Domande e risposte

Qual è il modo affidabile più rapido per iniziare?

Usa il più piccolo caso rappresentativo, scrivi il risultato atteso e cambia una variabile. Conferma il percorso base prima di aggiungere filtri, effetti, modifiche, automazione o una sorgente maggiore.

Quali prove vanno salvate?

Conserva identità dell’input, versione, piattaforma, impostazioni, azione esatta, prima transizione inattesa e output finale. Chiudi e riapri progetto, sessione, report o export prima di considerarli durevoli.

Quando va ripetuta la procedura?

Ripetila dopo cambiamenti rilevanti ad applicazione, sistema, driver, firmware, modello, sorgente o workflow. Conserva il caso accettato precedente come riferimento non modificato.

Quando il risultato è pronto per la consegna?

Quando un’altra persona autorizzata identifica l’input, ripete l’azione, vede lo stesso risultato, comprende i limiti e apre l’artefatto senza stato locale non documentato.

Guide correlate

Queste pagine nella stessa lingua coprono le fasi vicine senza cambiare il proprietario canonico dell’argomento: