RTSP si connette ma non mostra video: cosa controllare prima di incolpare il lettore

Uno dei ticket di supporto della fotocamera più comuni sembra semplice: "l'URL RTSP si connette, l'autenticazione ha esito positivo, ma lo spettatore non mostra alcun video. L'istinto naturale è provare un altro giocatore. Ciò può essere utile, ma non risponde alla domanda tecnica: il flusso ha avuto esito negativo durante il controllo RTSP, la negoziazione SDP, la consegna RTP o la disponibilità del codec?" Per gli integratori CCTV, gli ingegneri VMS e i fornitori di telecamere, questa distinzione è importante. Un giocatore può nascondere la perdita di pacchetti, riutilizzare il vecchio stato del decodificatore o riprovare silenziosamente le modalità di trasporto. Un rapporto diagnostico dovrebbe spiegare quale parte del flusso si è rivelata sana e quale no.

Separare il successo del controllo dal successo dei media

RTSP è un protocollo di controllo. Una sequenza "DESCRIBE", "SETUP" e "PLAY" riuscita dimostra che la fotocamera ha accettato la sessione. Ciò non dimostra che i pacchetti RTP siano arrivati. Inoltre, non dimostra che il payload sia effettivamente H.264 o H.265 nella forma pubblicizzata da SDP.

Un utile primo passaggio registra:

• i codici di stato RTSP per "OPTIONS", "DESCRIBE", "SETUP" e "PLAY"
• se l'organismo dell'SDP contiene una sezione multimediale video
• il tipo di payload negoziato per la traccia video
• se i pacchetti RTP arrivano dopo "PLAY".
• se il timestamp RTP e i numeri di sequenza avanzano
• se il primo payload video contiene prove dei parametri del codec

Se il controllo ha esito positivo ma non arriva alcun RTP, il problema è solitamente il trasporto, il firewall, il NAT, la modalità fotocamera o la disponibilità del flusso lato server. Se arriva RTP ma non è presente un video pronto per la decodifica, il problema si sposta verso il payload, la pacchettizzazione o i metadati del codec.

Perché la SDP è il primo confine di prova

L'SDP comunica al client ciò che la telecamera afferma di inviare. Per H.264, gli ingegneri cercano i valori "rtpmap" e "fmtp" come la modalità di pacchettizzazione, l'ID a livello di profilo e i "set di parametri sprop". Per H.265, l'SDP può trasportare informazioni VPS, SPS e PPS in modo diverso e molti consumatori hanno limiti di supporto più rigidi.

Quando l'SDP indica H.264 ma i byte multimediali non contengono la struttura dell'unità NAL prevista, l'errore non è un generico "problema del lettore". Si tratta di una mancata corrispondenza tra i metadati pubblicizzati e la realtà del carico utile. Quando SDP omette i set di parametri e il flusso RTP non li invia mai in banda, un decodificatore potrebbe attendere per sempre.

Questo è il motivo per cui un flusso di lavoro di ispezione RTSP dovrebbe mantenere l’SDP accanto alle prove mediatiche, non sepolto nel registro del giocatore.

L'arrivo dell'RTP non è sufficiente

Anche quando arrivano i pacchetti RTP, il video può comunque fallire. I frame H.264 e H.265 spesso dipendono da pacchetti precedenti. Un pacchetto mancante può rendere indecodificabile la fetta successiva. La consegna fuori ordine può sembrare corruzione. Un payload che inizia a metà GOP potrebbe non essere pronto per la decodifica finché non vengono visualizzati il ​​fotogramma chiave e il set di parametri successivi.

Le prove minime da raccogliere sono:

• Continuità della sequenza RTP
• progressione del timestamp
• comportamento del bit marcatore
• coerenza del tipo di carico utile
• Categorie di unità NAL H.264 o H.265
• SPS, PPS e per visibilità H.265 VPS
• prima disponibilità dei fotogrammi chiave

Questo spiega perché "VLC lo riproduce" e "la nostra pipeline di analisi lo rifiuta" possono essere entrambi veri. Alcuni spettatori si riprendono in modo aggressivo. I sistemi di ingegneria spesso necessitano di prove pulite dagli standard.

TCP contro UDP è una scelta diagnostica

Il passaggio del trasporto RTSP da UDP a TCP è un passaggio comune per la risoluzione dei problemi, ma non deve essere trattato come una panacea. L'interlacciamento TCP può evitare il blocco delle porte UDP e ridurre la perdita di pacchetti causata dai criteri di rete. Può anche nascondere se il percorso UDP previsto per la distribuzione funziona.

Un buon rapporto sul campo registra entrambi i tentativi:

• RTSP su TCP interleaved: i media arrivano?
• RTP su UDP unicast: i pacchetti arrivano sulle porte negoziate?
• RTCP: il feedback del mittente mostra i tempi e il conteggio dei pacchetti?

Se TCP funziona e UDP fallisce, probabilmente la risposta non è il supporto dei codec. È probabile che si tratti del percorso di rete, del firewall, del NAT o dell'allocazione delle porte. Se entrambi i trasporti forniscono RTP ma la decodifica continua a non riuscire, ispeziona la struttura del codec.

Dove si adatta l'ispettore RTSP

RTSP Inspector è costruito per questo limite esatto. Non sta cercando di diventare un lettore video o un NVR. Cattura le prove relative alla sessione RTSP, all'SDP, al flusso RTP/RTCP e alla disponibilità H.264/H.265 in modo che un tecnico possa spiegare perché "connesso" non è diventato "video utilizzabile".

L'output utile non è uno screenshot di una finestra del lettore nera. È una risposta ripetibile:

• Il controllo RTSP è riuscito
• SDP pubblicizzava questo codec e tipo di payload
• L'RTP è arrivato o non è arrivato
• la sequenza dei pacchetti era continua o interrotta
• l'evidenza del parametro codec era presente o mancante
• l'azione successiva appartiene alla rete, alla configurazione della telecamera, al firmware o al consumatore del flusso

Questa è la differenza tra guardare uno streaming e diagnosticarne uno.