Correzione errore RTP nel flusso primario: diagnostica perdita di pacchetti, blocchi della fotocamera e macroblocchi in RTSP

Quando il flusso di una telecamera IP si blocca, si blocca o produce errori del decodificatore H.264, il sintomo visibile è solitamente in ritardo. La causa spesso appare prima nella sequenza RTP. Un pacchetto RTP mancante può rimuovere una porzione di dati video da cui dipendono i fotogrammi successivi. Nel momento in cui il lettore registra un errore di decodifica, le prove di rete potrebbero essere già scomparse.

Questo è il motivo per cui la risoluzione dei problemi RTP dovrebbe iniziare con numeri di sequenza, timestamp, tipo di carico utile, comportamento dei marcatori e struttura del codec prima di modificare le impostazioni casuali della telecamera.

Cosa ti dicono i gap nella sequenza RTP

Ogni pacchetto RTP porta un numero di sequenza. Per un flusso costante, la sequenza dovrebbe avanzare in modo prevedibile. Un gap significa che uno o più pacchetti non sono arrivati. Un salto all'indietro può indicare un riordino, una consegna duplicata, un comportamento di riavvio o problemi relativi ai confini di acquisizione.

Le domande pratiche sono:

• quanti pacchetti mancavano?
• la perdita si è verificata una o più volte?
• si è verificato vicino ai fotogrammi chiave?
• i report sui mittenti RTCP sono continuati?
• la sessione di controllo RTSP è rimasta attiva?
• il guasto del decoder si è verificato dopo il gap?

Questa prova può separare la perdita di rete dai bug del carico utile della fotocamera. Se le lacune nella sequenza sono in linea con la corruzione visiva, il caso è più forte. Se la continuità della sequenza è perfetta ma il carico utile non è formato correttamente, la diagnosi si sposta verso il comportamento del codificatore o della pacchettizzazione.

Perché H.264 e H.265 sono sensibili alla perdita

Il video compresso non è un elenco di immagini indipendenti. Gli interframe dipendono dai sistemi di riferimento. Una piccola perdita di pacchetto può danneggiare più del pacchetto immediato. I flussi H.264 e H.265 possono anche basarsi su set di parametri come SPS e PPS e H.265 aggiunge VPS. Se questi mancano, sono in ritardo o danneggiati, il software downstream potrebbe rifiutare lo streaming anche quando uno spettatore tollerante sembra riprendersi.

I sintomi comuni includono:

• macroblocchi o artefatti a blocchi
• blocchi seguiti da un improvviso recupero
• Errori del decodificatore di stile "riferimento mancante".
• lo streaming viene avviato ma nessun frame diventa pronto per la decodifica
• corruzione ripetuta dopo scene ricche di movimento

Questi sintomi da soli non bastano. Le prove RTP e codec li rendono utilizzabili.

Non confondere il jitter con la perdita

Jitter significa che i pacchetti arrivano con tempistiche irregolari. La perdita significa che i pacchetti non arrivano. Entrambi possono causare balbuzie visibili all'utente, ma richiedono soluzioni diverse.

Per verificare la presenza di jitter, controllare la progressione del timestamp e il tempo di arrivo. Per eventuali perdite, ispezionare gli spazi vuoti nella sequenza. Per individuare i bug del firmware della fotocamera, controllare la coerenza del carico utile e la struttura NAL. Un rapporto sul campo che dice solo "lo streaming è discontinuo" non dice a un tecnico di rete, a un tecnico del firmware o al fornitore VMS cosa modificare.

Il rapporto migliore dice:

• Gap nella sequenza RTP da N a N+M
• salto del timestamp osservato nello stesso punto
• La sessione RTSP è rimasta stabilita
• il tipo di carico utile è rimasto stabile
• La sezione H.264 era incompleta
• il frame IDR successivo ha ripristinato la disponibilità del decodificatore

Questo è un artefatto di supporto molto più forte.

UDP e TCP raccontano storie diverse

RTSP trasporta comunemente RTP su UDP o su TCP interleaved. UDP espone direttamente la perdita di pacchetti. TCP può far scomparire i percorsi UDP bloccati, ma può introdurre latenza e non dimostra che il percorso di distribuzione previsto sia integro.

Per la diagnostica, confrontare entrambe le modalità:

• UDP fallisce con interruzioni nella sequenza: ispeziona la perdita di rete, gli switch, il Wi-Fi, il firewall, il NAT o il comportamento di invio della fotocamera.
• UDP non riceve RTP: controlla le porte negoziate e la politica del firewall.
• TCP funziona ma UDP fallisce: sospetto percorso di rete anziché codec.
• entrambe le modalità mostrano un payload non valido: codificatore della telecamera, profilo di streaming o firmware sospetto.

La scelta del trasporto è una prova, non solo una casella di controllo del giocatore.

Come l'ispettore RTSP inquadra il problema

RTSP Inspector si concentra sulle prove del protocollo invece che sulla riproduzione. Cattura le osservazioni RTSP, RTP, RTCP e codec in modo che un caso di supporto possa essere riprodotto e spiegato. Ciò è importante quando lo stesso flusso si comporta in modo diverso in VLC, FFmpeg, un NVR, un servizio di acquisizione nel cloud e una pipeline di analisi.

L'obiettivo non è affermare che ogni flusso possa essere corretto localmente. L’obiettivo è identificare il proprietario del guasto:

• percorso di rete
• configurazione della telecamera
• pacchettizzazione del firmware
• supporto del decodificatore a valle
• limite del codec non supportato
• mancata corrispondenza prevista della distribuzione UDP/TCP

La perdita di RTP non è solo un sintomo del video. È un evento di protocollo misurabile. Una volta misurato, la conversazione per la risoluzione dei problemi diventa molto più breve.