SDP, H.264 e H.265 nella diagnostica RTSP: i metadati che decidono se il video può avviarsi

Molti errori RTSP vengono descritti come "il flusso della telecamera non viene riprodotto". Quella frase nasconde il confine diagnostico più importante: "cosa affermava la telecamera nell’SDP e il carico utile dei media corrispondeva a tale affermazione?" L’SDP è spesso la prima prova strutturata disponibile in una sessione RTSP. Dichiara tracce multimediali, tipi di payload, nomi di codec, frequenze di clock, URL di controllo e parametri specifici del codec. Se l'SDP è sbagliato, incompleto o non supportato dal consumatore, uno streaming può fallire prima che il primo frame venga decodificato.

Cosa dovrebbe dimostrare l’SDP

Dopo "DESCRIBE", un client dovrebbe sapere se lo streaming contiene video, quale tipo di payload è associato a quale codec e come deve essere impostata la traccia multimediale. Per la diagnostica della fotocamera, controllare:

• sezione multimediale "m=video".
• URL di traccia "a=control".
• Tipo di payload e nome codec a=rtpmap
• Parametri del codec a=fmtp
• H.264 "sprop-parameter-sets" quando presente
• Segnalazione H.265 VPS/SPS/PPS quando disponibile
• se è prevista la frequenza di clock pubblicizzata

Se l'SDP pubblicizza H.264 ma la telecamera invia qualcos'altro, il ricevitore non è irragionevole. Se l'SDP omette le prove dei parametri essenziali e il flusso non le invia mai in banda, il decodificatore potrebbe non avere informazioni sufficienti per iniziare.

I set di parametri H.264 non costituiscono una prova facoltativa

I decoder H.264 necessitano di informazioni sulla sequenza e sui parametri dell'immagine. Nelle distribuzioni di telecamere RTSP, questa prova può apparire in SDP, payload RTP in banda o entrambi. I problemi sorgono quando una fotocamera presuppone che il ricevitore sappia già qualcosa che non sa.

Una registrazione diagnostica pulita risponde:

• SPS era visibile?
• il PPS era visibile?
• i payload includevano un frame IDR?
• lo streaming è iniziato a metà GOP?
• l'ID a livello di profilo sembrava plausibile?
• la modalità di pacchettizzazione corrispondeva alla struttura del carico utile osservata?

Ciò è particolarmente importante quando un giocatore funziona e un altro no. Uno spettatore tollerante potrebbe sopravvivere a metadati discutibili. Una pipeline di registrazione, analisi o conformità potrebbe rifiutarlo.

H.265 aggiunge ulteriori limiti di compatibilità

H.265 è comune sulle fotocamere moderne, soprattutto quando la larghezza di banda conta, ma è meno supportato universalmente di H.264 negli strumenti più vecchi e nei consumatori integrati. H.265 fornisce anche prove VPS oltre a SPS e PPS. Una distribuzione che dice solo "RTSP funziona" potrebbe comunque non riuscire perché l'effettivo profilo codec o la consegna dei parametri si trova al di fuori del limite supportato dal consumatore.

Per i team sul campo, un articolo, un ticket o un report utile non dovrebbe dire solo "passa a H.264". Dovrebbe spiegare perché:

• l'attuale consumer non dispone del supporto H.265
• i set di parametri H.265 mancano o sono in ritardo
• il tipo di payload non corrisponde alla mappatura del codec prevista
• il flusso è valido ma al di fuori dei limiti del prodotto
• il profilo della fotocamera deve essere modificato per questo flusso di lavoro

Questo livello di chiarezza impedisce ripetute modifiche per tentativi ed errori.

L'SDP deve essere confrontato con l'RTP

L'SDP è un'affermazione. RTP è la prova che segue. I due devono essere confrontati.

Esempi:

• SDP afferma che il tipo di payload 96 è H.264, ma RTP arriva con un tipo di payload diverso.
• SDP contiene una traccia video, ma nessun RTP segue "PLAY".
• SDP dice H.265, ma il prodotto downstream supporta solo H.264.
• SDP omette i set di parametri e RTP non li invia mai prima delle sezioni.
• Arriva l'RTP, ma la struttura dell'unità NAL non è coerente con il codec pubblicizzato.

Questi casi richiedono diverse azioni successive. Senza confrontare SDP e RTP, sembrano tutti lo stesso vago errore "no video".

Perché l'ispettore RTSP fa emergere queste prove

RTSP Inspector è progettato per ingegneri del flusso, fornitori di telecamere e integratori CCTV che necessitano di prove ripetibili. Non è intenzionalmente un lettore multimediale generico. Il suo compito è ispezionare il percorso di controllo RTSP, i metadati SDP, il flusso RTP/RTCP e la disponibilità H.264/H.265.

Ciò rende l'output utile nelle conversazioni di supporto:

• fornitore della fotocamera: correggere l'SDP o la pacchettizzazione
• team di rete: correggere il percorso di consegna RTP
• Team VMS: modificare il profilo codec supportato
• integratore di campo: modifica il profilo del flusso o la modalità di trasporto
• cliente: capire perché la riproduzione non è una prova dell'integrità del protocollo

Nella diagnostica RTSP, SDP non è un testo standard. È il primo contratto offerto dallo streaming. Se il contratto viene rotto, il resto del gasdotto dovrà tirare a indovinare.