2026-06-02

Modifica RTP SSRC durante il flusso: debug di riavvii della telecamera, modifiche alla sorgente del flusso, reimpostazioni della sequenza e problemi del decodificatore

Come diagnosticare le modifiche RTP SSRC nei flussi della telecamera RTSP, reimpostazioni del numero di sequenza, discontinuità del timestamp, riavvii del codificatore della telecamera, flussi di failover e problemi del decodificatore.

RTP "SSRC" identifica la fonte di sincronizzazione di un flusso RTP. Quando cambia nel mezzo di una sessione RTSP, gli utenti potrebbero vedere blocchi, fotogrammi neri, desincronizzazione audio/video, video danneggiato, allarmi di perdita di pacchetti o ripristino improvviso del decodificatore. Le frasi di ricerca includono "RTP SSRC modificato", "Lo streaming RTSP si blocca dopo il riavvio della telecamera", "Reimpostazione del numero di sequenza RTP", "Discontinuità del timestamp RTP" e "La sorgente dello streaming della telecamera è cambiata durante lo streaming".

L'ispettore RTSP è utile perché questa non è una normale domanda del giocatore. Le prove principali risiedono nelle intestazioni dei pacchetti RTP, nei report del mittente RTCP, nei metadati della traccia SDP, nei numeri di sequenza e nei timestamp.

Cosa significa SSRC

In RTP, ciascuna fonte multimediale ha un valore SSRC. Una traccia video e una traccia audio solitamente hanno valori SSRC diversi. Il ricevitore utilizza SSRC insieme al tipo di carico utile, al numero di sequenza, al timestamp e ai rapporti RTCP per mantenere la continuità del flusso.

Se l'SSRC cambia, il ricevente deve decidere se questo è:

Una nuova fonte di sincronizzazione legittima.
Un riavvio del codificatore della telecamera.
Un failover su un altro codificatore.
Un bug del firmware.
Un problema di riscrittura NAT/proxy.
Un nuovo flusso è stato erroneamente mescolato nella stessa sessione.

Trattare tutte le modifiche SSRC come perdita di pacchetti è fuorviante.

Sintomi comuni

Una modifica dell’SSRC può produrre diversi sintomi visibili:

Il video si blocca per alcuni secondi.
Il decodificatore mostra "unità NAL non valida" o "quadro di riferimento mancante".
La riproduzione continua ma la latenza aumenta.
Audio e video si allontanano.
Il client registra la perdita improvvisa di pacchetti.
Picchi di jitter RTCP.
I numeri di sequenza ripartono da un valore piccolo.
Il timestamp RTP salta indietro o in avanti.

La domanda importante è se l’identità dei media sia cambiata contemporaneamente alla continuità della sequenza e del timestamp.

Riavvio della telecamera o riavvio dell'encoder

Molte telecamere IP riavviano la pipeline del codificatore senza chiudere la connessione TCP RTSP. La sessione di controllo può sembrare ancora viva, ma l'RTP cambia al di sotto di essa.

Prova:

Lo stesso ID sessione RTSP continua.
Modifiche all'RTP SSRC.
Il numero di sequenza RTP si riavvia.
Il timestamp RTP si riavvia o salta.
Il report del mittente RTCP modifica la mappatura.
Il fotogramma chiave viene visualizzato subito dopo il riavvio oppure il decodificatore attende fino al fotogramma IDR successivo.

Se il flusso viene ripristinato dopo il fotogramma chiave successivo, il problema potrebbe essere il riavvio del codificatore anziché la perdita di pacchetti di rete.

Failover e origini multimediali con carico bilanciato

Alcuni sistemi trasmettono flussi RTSP attraverso un gateway. Se il gateway commuta le telecamere a monte, le condutture di registrazione o i lavoratori del transcodificatore, il ricevitore potrebbe vedere un nuovo SSRC.

Questo può accadere con:

Ristreaming dell'NVR.
Bridge per fotocamere cloud.
Failover del proxy RTSP.
Firmware della fotocamera multi-encoder.
Server di flusso ridondanti.
Bilanciatori del carico che non preservano l'affinità multimediale.

Se le modifiche SSRC sono correlate al failover del backend, la correzione potrebbe appartenere al livello di inoltro.

Reimpostazione del numero di sequenza

I numeri di sequenza RTP sono a 16 bit e normalmente aumentano di uno per ciascun pacchetto nello stesso flusso. Potrebbe essere previsto un ripristino nello stesso momento della modifica dell'SSRC. Un ripristino senza modifica SSRC è più sospetto.

Confronti utili:

Vecchio intervallo di sequenze SSRC.
Nuovo primo numero di sequenza SSRC.
Tipo di carico utile prima e dopo.
Timestamp prima e dopo.
Comportamento del bit marker vicino al confine.
Se un fotogramma chiave viene visualizzato dopo il ripristino.

Questa distinzione è importante per la SEO perché molte persone cercano "reimpostazione del numero di sequenza RTP" e presumono la perdita di pacchetti, mentre la vera causa è la sostituzione della sorgente.

Discontinuità del timestamp

I timestamp RTP seguono l'orologio multimediale. Per i video questo è spesso 90 kHz. Se il timestamp salta indietro, un ricevitore potrebbe perdere fotogrammi o riordinarli in modo errato. Se salta molto in avanti, il comportamento del jitter buffer potrebbe cambiare.

Quando l'SSRC cambia, la discontinuità del timestamp può essere accettabile se il ricevitore la tratta come una nuova fonte. Quando SSRC non cambia, la discontinuità del timestamp spesso indica un orologio del mittente rotto.

RTSP Inspector dovrebbe mostrare chiaramente il limite del timestamp:

old SSRC: sequence 43120, timestamp 88210000
new SSRC: sequence 210, timestamp 3000

That kind of evidence is more useful than a player screenshot.

RTCP sender report changes

RTCP sender reports map RTP timestamps to wall-clock time. If SSRC changes, the receiver should watch for new RTCP sender reports.

Questions to answer:

Does the new SSRC send RTCP SR?
Does the old SSRC send RTCP BYE?
Does the camera announce source shutdown?
Is jitter calculated per SSRC or across the boundary?
Does packet loss accounting reset correctly?

If a tool merges statistics across SSRC changes, it may show false loss, false jitter, or false bitrate dips.

Decoder behavior

Even when RTP is valid, decoders need a clean frame boundary. For H.264 and H.265, recovery may require SPS/PPS/VPS and an IDR frame.

After an SSRC change, check:

Does the next access unit include a keyframe?
Are SPS and PPS repeated?
Does the SDP still match the actual stream?
Does payload type stay the same?
Does fragmentation restart in the middle of a frame?

If the new source starts with P-frames only, the receiver may show black video until the next keyframe.

Debug checklist

Use this workflow:

Identify all SSRC values per RTP track.
Locate the exact packet where SSRC changes.
Compare sequence numbers before and after.
Compare RTP timestamps before and after.
Check RTCP BYE and sender reports.
Check whether RTSP session ID changed.
Check whether payload type changed.
Look for keyframe or codec config after the boundary.
Separate source restart from network loss.
Export the boundary packets for firmware or gateway debugging.

Final diagnosis

An RTP SSRC change is not automatically a network problem. It can reveal camera encoder restart, RTSP relay failover, timestamp reset, media source replacement, or decoder recovery delay.

RTSP Inspector helps by showing the media evidence that players hide: SSRC, sequence number, timestamp, RTCP behavior, keyframe recovery, and the exact packet where the stream identity changed.

Prova riproducibile per «Modifica RTP SSRC durante il flusso: debug di riavvii della telecamera, modifiche alla sorgente del flusso, reimpostazioni della sequenza e problemi del decodificatore»

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 «Modifica RTP SSRC durante il flusso: debug di riavvii della telecamera, modifiche alla sorgente del flusso, reimpostazioni della sequenza e problemi del decodificatore» 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.