SPS/PPS H.264 mancante nei flussi RTSP: perché VLC viene riprodotto ma FFmpeg o Analytics non riescono

Un frustrante modello di errore RTSP è familiare agli ingegneri delle telecamere: "VLC riproduce lo streaming, ma FFmpeg, un VMS, una pipeline di analisi o un servizio di acquisizione nel cloud falliscono con errori di decodificazione. Il thread di supporto diventa spesso un dibattito su quale sia lo strumento "giusto". La domanda migliore è se lo streaming fornisce prove sufficienti dei parametri H.264 per un nuovo decoder." H.264 necessita di set di parametri di sequenza e set di parametri di immagine. Gli ingegneri di solito li chiamano SPS e PPS. Descrivono come dovrebbe essere decodificato il flusso di bit: "profilo, livello, dimensioni, comportamento di riferimento e struttura dell'immagine. Senza di essi, un decodificatore potrebbe vedere i dati delle sezioni ma non avere ancora un contesto valido per trasformarli in frame."

Dove possono apparire SPS e PPS

Nelle implementazioni RTSP, le prove SPS/PPS possono apparire in più di un luogo:

• SDP "set di parametri sprop".
• payload RTP in banda prima delle sezioni
• ripetuto prima dei fotogrammi chiave
• memorizzato nella cache da un giocatore tollerante da una sessione precedente
• consegnato solo dopo aver atteso il successivo IDR

Questo spiega il problema "funziona in un visualizzatore". Un giocatore può riutilizzare lo stato, attendere più a lungo, ripristinare i riferimenti mancanti o applicare l'occultamento degli errori. Un servizio di acquisizione rigoroso può iniziare con un decodificatore vuoto e rifiutare il flusso fino all'arrivo di SPS/PPS e di un fotogramma chiave utilizzabile.

Cosa significa effettivamente l'errore

Messaggi come "immagine mancante nell'unità di accesso", "errore intestazione porzione di decodifica", "riferimento PPS inesistente" o "in attesa di SPS/PPS" non significano automaticamente che la fotocamera è rotta. Significano che il decodificatore non aveva il contesto dei parametri di cui aveva bisogno nel punto in cui ha tentato di decodificare.

Le domande diagnostiche sono:

• SDP includeva "set di parametri sprop"?
• SPS e PPS sono stati visualizzati nel payload RTP?
• sono arrivati ​​prima della prima fetta?
• è apparso un frame IDR dopo i set di parametri?
• la perdita di pacchetti ha rimosso il pacchetto del set di parametri?
• lo streaming è iniziato a metà GOP?
• il tipo di carico utile era coerente con l'SDP?

Una volta data risposta a queste domande, l’azione successiva diventa più chiara.

Perché gli avvii dello streaming a metà GOP sono rischiosi

Molte telecamere iniziano a inviare dalla posizione corrente dell'encoder quando il client RTSP si connette. Se il client si unisce a metà GOP, potrebbe ricevere inter frame prima di un key frame. Se anche il flusso non riesce a ripetere SPS/PPS regolarmente, il decodificatore potrebbe attendere o fallire fino al successivo confine adatto.

Per il software di monitoraggio, questo può assomigliare a:

• schermo nero per diversi secondi
• il primo fotogramma viene visualizzato solo dopo l'intervallo del movimento o del fotogramma chiave
• la pipeline di analisi rifiuta il flusso
• il restreamer si avvia ma i client downstream falliscono
• ripristino occasionale dopo la riconnessione

La correzione potrebbe essere lato telecamera: ridurre l'intervallo dei fotogrammi chiave, ripetere i set di parametri, utilizzare un profilo di flusso diverso o passare da H.265 a H.264 se il prodotto downstream ha un supporto più rigoroso.

L'SDP è un reclamo; L'RTP ne è la prova

Alcuni sistemi di telecamere pubblicizzano SPS/PPS in SDP. Altri si aspettano che il decodificatore attenda le unità NAL in banda. Alcuni fanno entrambe le cose. Alcuni non lo fanno correttamente. Un rapporto diagnostico dovrebbe confrontare il reclamo con il carico utile.

Le prove utili includono:

• set di parametri base64 in SDP
• Tipi di unità NAL H.264 osservati in RTP
• primo indice dei pacchetti SPS/PPS
• primo indice del pacchetto IDR
• perdita di pacchetti prima della disponibilità del fotogramma chiave
• stato di disponibilità del decodificatore

Questo è molto più forte di "provare un altro giocatore". Indica al fornitore se modificare l'SDP, le impostazioni del codificatore o il comportamento della pacchettizzazione.

Dove si adatta l'ispettore RTSP

RTSP Inspector è progettato per ispezionare RTSP, SDP, RTP/RTCP e la struttura del codec senza pretendere che la riproduzione sia la diagnosi. Per i casi SPS/PPS mancanti, il prodotto dovrebbe aiutare gli ingegneri a mostrare:

• lo streaming si è connesso correttamente
• L'SDP trasportava o meno set di parametri
• RTP ha fornito o meno set di parametri
• la perdita di pacchetti ha influenzato o meno il primo limite di decodifica
• l'errore riguarda i metadati dello streaming, la distribuzione in rete, il supporto del decoder o la configurazione della telecamera

Questo è il tipo di prova che risolve l'argomento "VLC funziona". Il funzionamento di VLC è un'informazione utile. Non è una prova che il flusso sia pulito per ogni consumatore.

Se la query di ricerca è "RTSP funziona in VLC ma FFmpeg fallisce", controlla SPS/PPS, fotogrammi chiave, perdita di pacchetti e SDP prima di incolpare il sistema downstream.